The Solidity Contract-Oriented Programming Language - By chatting here you agree to the https://github.com/ethereum/solidity/blob/develop/CODE_OF_CONDUCT.md
@VoR0220 http://ethereum.stackexchange.com/
and have the addresses of both contracts on the blockchain
will
h = new Helper("abc", true); make a new contract ?
contract Helper {
bytes3 name;
bool flag;
function getName() returns (bytes3 ret) { return name; }
function getFlag() returns (bool ret) { return flag; }
}
contract Main {
Helper h;
function init(address helperAddress){ h= Helper(helperAddress) }
function getFlag() returns (bool ret) { return h.getFlag(); }
function getName() returns (bytes3 ret) { return h.getName(); }
})
just a variation will this work ?
I'm experiencing unexpected behavior that is consistent between the go, python, java, and JS EVMs. When a transaction runs out of gas, what's supposed to happen? I sent the same transaction twice with different amounts of gas. With 3,000,000 gas, it succeeds. Without specifying the amount of gas, web3 sent 90,000 gas and crashed with a bad JUMPDEST. Looking at the VM trace, the contract subtracts the gas for a call from the amount of gas remaining, but that value ends up rolling over to a negative number (or a large unsigned integer). I suspect this is involved in the bad JUMPDEST crash, but I don't know how a Solidity contract could ever generate a bad JUMPDEST.
Looking for guidance on whether this is a bug and where to file it.
Sounds like not a bug. I think we should get that information into all the documentation that references JUMPDEST though.
fyi to whoever answers, best to post here: http://ethereum.stackexchange.com/questions/693/how-can-i-sign-a-piece-of-data-with-the-private-key-of-an-ethereum-address
If you need an account, you should be able to sign in here: https://area51.stackexchange.com/proposals/89704/ethereum (or ask anyone here for an invite)
Documented my JUMPDEST issue here: https://ethereum.stackexchange.com/questions/694/what-does-a-bad-jumpdest-error-mean/695#695
@pipermerriam I rolled my own code that I'll paste in an answer on Stack Overflow.
Internall, it seems Solidity places some guards in place when issuing call(). It doesn’t automatically forward ALL the gas to the sub-call. It subtracts some gas to keep around. However, I’m not exactly sure how it determines what amount of gas to keep around. Does anyone know? @chriseth?
@simondlr this is one of the quirky places of the EVM. You cannot just say "send all my gas along with the call", you always have to give an explicit number. We do have the
GAS opcode which gives us the amount of gas still available, but the problem is that performing the call itself also costs some gas, so we have to subtract the amount of gas the call costs from the value provided by GAS, and we also have to subtract the amount of gas it costs to perform the subtraction...
Alright, got a hard one for you guys: http://ethereum.stackexchange.com/questions/720/why-isnt-my-contract-getting-a-msg-sender-solc-0-2-0-1
can anyone help me with this one ?
@agatsoh please don’t delete the questions, even if it’s a trivial answer. I made effort looking through your code to give an answer, and it will help others in the future if they experience similar problems.
@simondlr should I edit this question a bit because I found the answer myself
any idea why it returns 0 in online compiler ?
oh, ignore
now (uint): current block timestamp (alias for block.timestamp)
it was a typo because I was checking this issue and trying different things out. I am sorry for that @simondlr
@simondlr Here is a new one http://ethereum.stackexchange.com/questions/735/error-in-calling-events-in-solidity
