WerWolv / ImHex

🔍 A Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at 3 AM.
https://imhex.werwolv.net
GNU General Public License v2.0
44.8k stars 1.95k forks source link

[Bug] Unable to enter 128-bit values in pattern field #1232

Open soxfox42 opened 1 year ago

soxfox42 commented 1 year ago

Operating System

Windows

What's the issue you encountered?

The pattern data panel is unable to set values above the maximum of a 64-bit integer, so u96 and u128 fields can't be edited easily.

How can the issue be reproduced?

  1. Create or open a file with at least 16 bytes.
  2. Execute the following pattern; u128 value @ 0x00;
  3. In the pattern data panel, set value to some number above 2^64.

Instead of the expected value, the field will be set to 2^64 - 1 (maximum 64-bit value).

ImHex Version

1.30.1, 1.31.0

ImHex Build Type

Installation type

MSI

Additional context?

No response

github-actions[bot] commented 2 weeks ago

This issue is marked stale as it has been open for 11 months without activity. Please try the latest ImHex version. (Avaiable here: https://imhex.download/ for release and https://imhex.download/#nightly for development version) If the issue persists on the latest version, please make a comment on this issue again

Without response, this issue will be closed in one month.

soxfox42 commented 2 weeks ago
Screenshot 2024-10-20 at 13 11 24

This issue is still present. I tried setting both of these fields to 20000000000000000000, which is greater than 2^64, and they were clipped to 2^64 - 1.

paxcut commented 2 weeks ago

The error seems to occur only if you enter the value as a hexadecimal. Using decimal values seems to work for any size. Until this bug gets fixed a work-around is to simply enter the value directly into the the hex editor and rerun the pattern to update the data display.

soxfox42 commented 2 weeks ago

Decimal values don't work for me, it might be a platform-specific thing? I entered the decimal value 20000000000000000000, and that caused the issue.

The workaround is good though, and I think that's how I dealt with it back when I first encountered this issue.

paxcut commented 2 weeks ago

I could have sworn it worked when I tried using decimal but I must have been seeing things cause like you say it doesn't work there either. It is probably using a u64 variable to set it, but I have to check that. Sorry about the confusion.

soxfox42 commented 2 weeks ago

All good. I think when I looked into it, I found that it was due to the integer parsing function from the standard library only returning u64, and there isn't a built-in equivalent for 128-bit values, so a new one would need to be written. I could be wrong, since I haven't gone back to check.