Compiler error on attempting to use hexadecimal literals of length 39-41 as integers
- Dominant language
- C++
- Stars
- 25.7k
- Forks
- 6.2k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 21
Description
## Description
Attempting to use a hexadecimal literal of length 39 as integer leads to the following compilation errors:
- SyntaxError: This looks like an address but is not exactly 40 hex digits. It is 39 hex digits. If this is not used as an address, please prepend '00'.
- TypeError: Built-in binary operator / cannot be applied to types uint256 and address.
Attempting to use a hexadecimal literal of length 40 as integer leads to the following compilation error:
- TypeError: Built-in binary operator / cannot be applied to types uint256 and address.
Attempting to use a hexadecimal literal of length 41 as integer leads to the following compilation errors:
- SyntaxError: This looks like an address but is not exactly 40 hex digits. It is 41 hex digits. If this is not used as an address, please prepend '00'.
- TypeError: Built-in binary operator / cannot be applied to types uint256 and address.
I assume that these errors are as part of allowing the usage of address literals without an explicit cast.
For example, allowing `address x = 0x1234...` instead of requiring `address x = address(0x1234...)`.
In other words, a hexadecimal literal of length 39-41 is assumed `address` instead of `uint256`.
You should by the least fix the error message for length 39 (need to prepend '000', not '00'), and for length 41 (need to prepend '0', not '00').
It is my opinion that you should also interpret a hexadecimal literal of length 39-41 as `uint256` instead of `address`.
Obviously, that would prevent the usage of address literals without an explicit cast, so perhaps what's needed here is a context-based decision.
For example, interpret the hexadecimal literal as a `uint256` if used in a "uint" context, and as an `address` if used in an "address" context.
## Environment
- Compiler version: 0.8.27
- Target EVM version (as per compiler settings): Paris I suppose?
- Framework/IDE (e.g. Truffle or Remix): Truffle-based Hardhat
- EVM execution environment / backend / blockchain client:
- Operating system: MacOS
## Steps to Reproduce
```solidity
function test(uint256 x) external pure returns (uint256) {
uint256 a = x + 0x123456781234567812345678123456781234567; //39 digits
uint256 b = x + 0x1234567812345678123456781234567812345678; //40 digits
uint256 c = x + 0x12345678123456781234567812345678123456789; //41 digits
return a + b + c;
}
```
Contributor guide
Research direction
Start by reproducing the Solidity 0.8.27 example with 39-, 40-, and 41-digit hexadecimal literals, then trace how hexadecimal literals are classified and how the diagnostic is generated. Done means the reported padding guidance is correct and the intended integer-versus-address behavior is resolved with regression coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, solidity
- Domain
- blockchain, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100