ethereum/solidity

The Solidity Contract-Oriented Programming Language - By chatting here you agree to the https://github.com/ethereum/solidity/blob/develop/CODE_OF_CONDUCT.md

Micah Zoltu

@MicahZoltu

Something with { value: amount } or something?

Is that a thing or was I dreaming?

I'm not finding any documentation abou tit.

CJ42

@CJ42

@MicahZoltu it is possible to control the supplied ether value in a low level call as follow (change _addressProvided and calldataProvided by what you want, the calldata must be of type bytes memory)

address(_addressProvided).call{value: 1 ether}(_calldataProvided);

You can do the same to adjust the gas supplied:

address(_addressProvided).call{gas: 1000000}(_calldataProvided);

See here in the docs

Micah Zoltu

@MicahZoltu

@CJ42 That is in 0.6.8?

And it has to be wrapped in address(...)?

CJ42

@CJ42

@MicahZoltu SInce 0.6.2
Before that, the syntax was slightly different

For your other question, I never looked at it. But it does not seem to need to be wrapped inside address(...)
address(...) just work for type casting. So using that will depend on your use case.

The code below compiles:

pragma solidity ^0.6.0;

contract Example {

    // assuming this contract has a ``register(_name)` function
    address contractToCall = 0xABaBaBaBABabABabAbAbABAbABabababaBaBABaB;

    function test() public {
        bytes memory _calldata = abi.encodeWithSignature("register(string)", "MyName");
        contractToCall.call{value: 1 ether}(_calldata);
    }

}

Micah Zoltu

@MicahZoltu

It appears you do need to wrap in address if you have a contract. This makes me sad.

The full code to send ETH to a contract in a non-sucky way is:

(bool success,) = address(apple).call{value: 1 ether}("");
require(success);

Which has a pretty terrible UX. :cry:

CJ42

@CJ42

What is the variable type of ‘apple’ ? Address or address payable?

elizabeth-g-28

@elizabeth-g-28

@chriseth, even if we add in a struct. Is there any way to create the product ID automatically for the given number of quantity

chriseth

@chriseth

@MicahZoltu contracts are not meant to be sent ether without a semantic component. A plain ether transfer only makes sense to a non-contract address. If you want to send ether to a contract, you should tell it what it is supposed to do with the ether: c.invest{1 ether}() c.donate{1 ether}() and so on

Micah Zoltu

@MicahZoltu

@chriseth Contracts that want to support EOA deposits will create a receive/fallback function. It seems silly to require that such contracts implement a second method that does the same thing. Sure, you can just have one call the other, but why not just let contracts easily send value to other contracts?

chriseth

@chriseth

If the contract just wants to mimick an EOA deposit, it should look like an address

and that's why you need the cast

the problem with the other syntax is that we have not found a good replacement for send / transfer yet

Micah Zoltu

@MicahZoltu

Yeah, I saw that the docs still recommend them and recommend against .call. This makes me sad.

Is the issue just trying to come up with a name?

If the arbitrary call syntax was a bit easier to use you could use that. ;)

Cyril Lapinte

@sirhill

I've just checked 0.6.9. The error message is documented in the release note but it's not very explicit: "Warning: Only state variables can have a docstring. This will be disallowed in 0.7.0". Furthermore it hints toward the 'storage' keyword rather than the variable name.
What is the recommended fix ?

Cyril Lapinte

@sirhill

Ok I've found my issue. It was the following comment one line above: /**** STORAGE ****/ next line confused the natspec parser i believe. The fact it was a local storage variable created the error on the next line. Happy to provide debug info.

chriseth

@chriseth

@MicahZoltu yes, just a new name. Or decide that we can just increase the gas amount in the next breaking release

@sirhill oh that's interesting! It should only check /** - i.e. double star. Can you create an issue for that?

Cyril Lapinte

@sirhill

Sure

chriseth

@chriseth

Thanks!

Cyril Lapinte

@sirhill

I didn't have time yet to do all my checks on storage structure writing at once vs multiple writes. I want to test also how the size of a structure impacts the the gas cost. I am expecting interesting results :-)

chriseth

@chriseth

cool!

Alex Stokes

@ralexstokes

is anyone here familiar w/ the ABIEncoderV2?

i've been debugging a function that calls one of the BLS precompiles in the upcoming Berlin hardfork

i have a test written in python using py-evm where i've added the precompiles

i'm taking advantage of the ABIEncoderV2 features to e.g. pass around structs

and i'm running into some issues that I think (after ruling out other things) may lie w/ the encoder

here is the contract for reference; the particular function is mapToCurve

https://github.com/ralexstokes/deposit-contract-verifying-proxy/blob/add-testing/contracts/deposit_contract_proxy.sol#L222

the issue w/ the {de,en}coding of the structs Fp2 and G2Point, as far as i can tell

as basic types, the structs are each just bundles of uint256 so nothing exotic

Alex Stokes

@ralexstokes

the first weird thing is that in the assembly, input turns into an address in memory that is lower than the Fp2 data. for the inputs and outputs to line up, i have change line 228 (https://github.com/ralexstokes/deposit-contract-verifying-proxy/blob/add-testing/contracts/deposit_contract_proxy.sol#L228) to add(input, 0x40), and I'm not sure why

at this point, i can watch the EVM state and see that the precompile executes successfully and returns the expected output in memory

the second issue is that in between returning from the precompile and returning from the function (where there is not much solidity source going on...), i eventually hit a MLOAD that pops the following number off the stack 7316785600067001156560257927453687096 which tries to extend memory and then i run out of gas (as expected)

so my best guess at the moment is that there is an issue w/ returning a G2Point instance from the function which points to ABIEncoderV2 (although it could easily be something else...)

Alex Stokes

@ralexstokes

(to confirm my suspicion that the bug lies w/ the encoder, if i change the function to return bytes memory i get back the expected bytes no problem)

Alex Stokes

@ralexstokes

so the 7316... number being read from the stack is the start of the desired data (that does end up in memory first)

Sven Arild Helleland

@kaizen-sven

I just started working with Solidity a few days ago, and have read two books on the subject, and done a few tutorials. When I started writing my own contract from scratch I just ran into an issue not described in the books or tutorials I've read so far.

Is it correct that on a call to the contract, if you include any other calls to internal methods, they cannot read any data you have added to storage earlier in the call (i.e. in another method)?

Running into "invalid opcode" VM exceptions if I try to access data I just stored. So uncertain if this is due to a limitation in how Solidity works, or if I storing the data wrong in the other methods.

Note. When I comment out the lines of code that try to access this data, the VM exception disappears.

Alex Stokes

@ralexstokes

@kaizen-sven i'd take a look at the contracts if you can link them

my intuition says you should be able to see earlier writes -- everything would boil down to a SSTORE/ SLOAD and the EVM should execute such that if you put something at a storage slot you should be able to read it back later

if the overall transaction (or a call inside the transaction) fails then the state changes are not persisted

Sven Arild Helleland

@kaizen-sven

@ralexstokes thanks, I have created a small test case, showing the issue here.

In short, when I try to access the details stored in createAccount() inside handleLevel() during the same call, it throw the "invalid opcode"
https://www.paste.org/106389

Here is also the truffle unit test
https://www.paste.org/106390

Sven Arild Helleland

@kaizen-sven

@ralexstokes I managed to figure out what happened. Turns out as I stored a list of uint8 inside a struct, if modified the values after I stored the struct into the mapping storage, it works.

I initially modified the values before I added it to the mapping storage, and that did not keep the state.

Thanks again for volunteer to help out!

Sajan Maharjan

@MaharjanSajan_twitter

hi! i would like some help from solidity savvys from this group
I want to make a simple interest contract in solidity and i have written the following code

contract InterestPayment {
    using SafeMath for uint256;
    address payable public depositor;
    address payable public bank;
    uint256 public rate;
    uint256 public timeperiod;
    uint256 public endtime;
    uint256 public principal;
    uint256 public interest;
    uint256 public amt;

    constructor() public {
        bank = 0x588bA1E08490d7DB2736Fa6E8BD403Ec3681dD8B;
    }

    modifier endTimeElapsed() { 
        require(now >= endtime); 
        _; 
    }

    modifier callFromDepositor() {
        require(msg.sender == depositor);
        _;
    }

    function makeDeposit(uint256 _principal, uint256 _rate, uint256 _tp) payable public {
        timeperiod = _tp;
        endtime = now + timeperiod;
        rate = _rate;
        principal = _principal;
        depositor = msg.sender;
        bank.transfer(_principal);
    }

    function receiveBack() payable public endTimeElapsed callFromDepositor returns(string memory) {
        uint256 ptr;
        require(now >= endtime && msg.sender == depositor);
        ptr = (principal.mul(rate)).mul(timeperiod);
        interest = ptr.div(100);
        amt = principal.add(interest);
        depositor.transfer(amt);
        string memory _text = "Amount has been paid with interest";
        return _text;
    }
}

the code compiles successfully and is deployed successfully on private chain as well. However, when I call the makeDeposit function, my program return a VM Exception while processing transactions. Could anybody help me here, possibly pointing out what wrong I have done. Thanks!!

Where communities thrive

People

Repo info

Activity