argotorg / argotorg/solidity

Compiler error on attempting to use hexadecimal literals of length 39-41 as integers

Open
#15,427 1 comment 0 reactions 0 assignees View on GitHub
bug :bug: low effort low impact
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.