ZTree.com  | ZEN  | About...  

 Index   Back

[Bug] Cannot set large offset in File View/Hex, with Hex input   [Bug]

By: Nuno       
Date: Jan 05,2021 at 10:29
In Response to: [Bug] Cannot set large offset in File View/Hex, with Hex input (Ben Kent)

> > (...)
> > There is some kind of 8byte truncation on hex input, max value seems
> to
> > be FFFFFFFFH.
> >
> >
> > Tested with ZTreeW64 v2.4.199
> >
> > Thanks
> > Nuno
>
> Going by your description, my first thought was it's a 32bit interget
> overflow issue, but investigating it's not as simple as that.
>
> 2^28=010000000H works
> 2^31=080000000H works
> 7FFFFFFFH goes to 07FFFFFC0H, expected
> FFFFFFFFH goes to 0FFFFFFC0H, expected
> 2^32=100000000H goes to 010000000H, incorrectly
>
> At the start of a file Offset 100000000H incorrectly goes to 010000000H
> as you report.
>
> But also there seems to be some relative position behaviour, I viewed a
> 19GB file, End, Offset 100000000H, took me to 410000000H. Also at the end
> of that file the last line has position 4B2D143EA, going to offset
> 4B2D143EAH took me to 44B2D1400H.
>
>
> Ben

Hi Ben
Thanks for your testing.
I also noticed that odd behaviour you are referring, on other testing.
That's why I suspect it's "only" a input truncation of some sort, or a bad conversion subroutine from hex.
Sometimes, there seems to "leak" the first (most significant) character, and that "relative" behaviour seems to occur. But thats just a side effect, and it seems unusable anyway.
Also, since the decimal input works correctly, the "internals" should be ok.
Most probably the source is already using a 64bit number, and I suspect it should be easy to track this down, looking at the source code inside the input or conversion functions.

But now, since we were "exposed" to that "relative" behaviour, that seems to me a great improvement for Kim to handle... [ZEP] Supporting "relative" offsets!
It's not for everyday use, but... I would have used it, previously.

Something like:
+10000 -> move to 10k position from the current offset
-FFFFH -> move FFFF bytes to the left (if possible, of course)

That is, relative offset within offset!

Also,
Have a great 2021!
--
And many thanks to all this great work to Kim Henkel and whoever supports him!

Nuno

123 views      
 

Messages in this Thread

 
95,371 Postings in 12,032 Threads, 350 registered users, 46 users online (1 registered, 45 guests)
Index | Admin contact |   Forum Time: May 7, 2021 - 8:16 pm UTC  |  Hits:39,364,363  (11,230 Today )
RSS Feed