Deprecate variable argument mode of keccak256/sha256/ripemd160

[axic]

Right now these functions accept a variable number of arguments and produce a tight packed version.

Some warnings are already displayed for tight packing literals. #982 proposes to turn those warnings into errors.

The new abi.encode*() methods offer a replacement to perform packing, which then can be passed to all these hashing functions.

Proposal is to raise a warning now when these hashing functions receive multiple arguments or the first and only argument isn't of bytes type.

[axic]

A deprecation warning could be added which suggest to use keccak256(abi.encodePacked(...)).

[chriseth]

This should also include call and delegatecall. Especially for those, empty arguments should be fine without warning.

[chriseth]

Result of discussion: Add a warning for hash functions, and do the rest (including call*) with 0.5.0 proper.

[chriseth]

Related: #3789

[AlexeyAkhunov]

Hi guys! I have noticed that there is a difference between versions 0.4.23 and 0.4.24 in how code for keccak256(abi.encodePacked(...)) is generated. In version 0.4.23, the memory segment which is result of abi.encodePacked is passed directly to keccak256, but in 0.4.24, an extra loop is generated, to create another copy of the same byte string in memory, before passing it to keccak256(). Both behaviours are equivalent, it is just 0.4.24 generates more code and spends more gas. Was it interntional?

[chriseth]

@AlexeyAkhunov are you sure this is really the case or are you comparing sha3(x) to sha3(abi.encodePacked(x))? This will be optimized for 0.5.0, but we can only do it with a breaking change, I think.

[AlexeyAkhunov]

@chriseth This was specifically the line I was looking at: https://github.com/gnosis/safe-contracts/blob/76b70e83151530fa5d72d45f937abed8294be01a/contracts/GnosisSafePersonalEdition.sol#L152

I tried to do "solc --asm" (without optimiser) with 0.4.23 and 0.4.24, and there was an extra loop generated with 0.4.24. I will double-check again

[AlexeyAkhunov]

@chriseth I am going to make a very small 1-line example and confirm if it occurs there

[AlexeyAkhunov]

@chriseth I made a small example, and the loop is generated in both versions. I must have missed it somehow the first time. Sorry for trouble

[AlexeyAkhunov]

@chriseth I was indeed looking at the version which did not have abi.encodePacked() function earlier. Mystery is solved