Skip to content

[ZkTracer] fix conversion bytes to int/long #2375

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
letypequividelespoubelles wants to merge 1 commit into
base: main
Choose a base branch
from
+4 −2
Open

[ZkTracer] fix conversion bytes to int/long #2375

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions tracer/arithmetization/src/main/java/net/consensys/linea/zktracer/types/Conversions.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@ public static Bytes booleanToBytes(boolean x) {
public static long bytesToLong(final Bytes input) {
final Bytes trimmedBytes = input.trimLeadingZeros();
checkArgument(trimmedBytes.size() <= 8, "Input bytes must be at most 8 bytes long");
return trimmedBytes.toLong();
return trimmedBytes.toUnsignedBigInteger().longValueExact();
}

public static short bytesToShort(final Bytes input) {
Expand All @@ -134,7 +134,9 @@ public static String bytesToHex(byte[] bytes) {
}

public static int bytesToInt(Bytes bytes) {
return bytes.trimLeadingZeros().toInt();
final Bytes trimmedBytes = bytes.trimLeadingZeros();
checkArgument(trimmedBytes.size() <= 4, "Input bytes must be at most 4 bytes long");
return Math.toIntExact(bytes.trimLeadingZeros().toLong());
Copy link
Contributor

@OlivierBBB OlivierBBB Feb 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I solved the same issue I think on the 7702 HUB PR by letting LEAD_DELEGATION_BYTES be a long rather than an int. Probably best to use the same approach in both PR's.

Copy link
Contributor Author

@letypequividelespoubelles letypequividelespoubelles Feb 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it could work as well. But the issue is that this functiun can be called elsewhere and has to be fixed anyway. And once it's fixed, there is no need to have the leading bytes as long, as it's an (unsigned) int. Or the best would be to have leadingBytes a Bytes of length 4 ...

Copy link

@cursor cursor bot Feb 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant trimLeadingZeros() call instead of reusing variable

Low Severity

In bytesToInt, the local variable trimmedBytes is computed on line 137 but then line 139 calls bytes.trimLeadingZeros() again instead of using trimmedBytes. This is redundant computation and inconsistent with the pattern in bytesToLong, which correctly reuses its trimmedBytes variable. The conversion on line 139 likely intended to be trimmedBytes.toLong().

Fix in Cursor Fix in Web

Copy link

@cursor cursor bot Feb 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bytesToInt throws for valid 4-byte address fragments

High Severity

The new bytesToInt uses Math.toIntExact(bytes.trimLeadingZeros().toLong()). For 4-byte inputs where the high bit is set (unsigned value > Integer.MAX_VALUE), .toLong() zero-extends to a positive long exceeding int range, causing Math.toIntExact to throw ArithmeticException. The existing caller in RomLex passes operation.byteCode().slice(3, 4) (an Ethereum address high part), which can have any byte value — roughly half of all addresses will crash the tracer.

Fix in Cursor Fix in Web

}

/**
Expand Down
Loading