Instead it should display as C0, the same way as UInt8.
This is due to converting it to a signed Int8 that is then passed on to a (U)Int32 or an (U)Int64, at which point a sign extension happens, which show as leading F's.
Also look how others handle this, as usually hexadecimals are always positive, but in this case Int8 and UInt8 just show the same information twice.
But it also affects the goto command (when clicking on a data row's "go to:" link), as this always expects a positive value (negative ones make no sense as file position).
What about IntToHex in other languages like C orJava. How do they handle negative values?
Same issue happens with Int16. But not Int32 or Int64, since they don't get sign extended, but passed on IntToHex without a type cast (and IntToHex treats them always as unsigned internally).
Make sure this matches with IntToBase/IntToOffsetBase handling of negative values, i.e., both the data inspector hex value display and the former functions should give the same results, for consistency.
Relative jumps (short/near jumps) x86 have a similar problem. The can have an immediate relative offset, that usually is shown with leading F in case of negative offsets in hexadecimal. But it might be nicer showing it with a - or + sign, always!
This would disambiguate it from having a hexadecimal value which is shown as unsigned, no matter the signedness of the type.
See also how debuggers handle relative jumps, or actually the relative offset in hexadecimal. See this in Delphi/VS, etc.
Bug reports concerning HxD.
1 post • Page 1 of 1