This change is made to (easily) be forward compatible with future C++
standards, in order to allow compiling the code with newer standards at
some point in the future.
* Removed the `using byte = uint8_t;` line from Common.h
* Mechanically change all uses of `byte` to `uint8_t`.
Tested with GCC 7.3 in C++11/14/17 modes :-)
Removed push/pop if there was no change to the warnings *in the same
file* for a given compiler. This assumes the imported boost headers use
a warning stack themselves.
The pragmas don't seem to be required anymore, but were not removed to
mantain compatibility with older versions of the boost library.
Compiled with
- clang version 6.0.1 (tags/RELEASE_601/final)
- gcc (GCC) 8.1.1 20180531
against:
- libboost 1.67.0-5
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.
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.
