| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
The previous macro used the set built-in in a way incompatible with the current
implementation of set. This commit updates the macro to be more transparent in how it's
working and avoids the use of the set and alloc built-ins.
|
| |
|
|
|
|
| |
When (msize) is initially zero the previous create commands failed due to the "lll"
expression overwriting the memory at 0x00. This fix "reserves" memory location 0x00
before calling msize. If msize is already 32 or greater it has no effect.
|
| |
|
|
| |
(r s v hash) -> (hash v r s) which corresponds to the order that the built-in EVM contract uses.
|
| | |
|
| |
|
|
|
|
| |
When PR #2317 changed the EVM opcode from SHA3 to KECCAK256 it broke the `(sha3 loc len)` expression in LLL. This PR fixes things while allowing existing code using the sha3 expression (such as the ENS registrar) to continue to compile. I.e. both `(keccak256 loc len)` and `(sha3 loc len)` may be used, and the existing related sha3 macros continue to work.
Three end-to-end test cases have been added for kekkac256 and sha3.
|
| |
|
|
|
|
| |
EIP-141 ethereum/EIPs#141 has preserved 0xfe as an invalid opcode for aborting EVM execution. The EVM assembler supports this via the INVALID opcode.
The LLL "panic" expression used to generate a jump to an invalid location in order to abort EVM execution. This change brings "panic" into line with EIP-141 by generating the INVALID opcode instead.
|
| | |
|
| | |
|
| |
|
|
| |
'keccak256' in addition to 'sha3'.
|
| |
|
