Incorrect spacing on last line of output

[rm-hull]

Hey there, If I print a string:

const dummyJwtPayload =  `{"client_id":"YzEzMGdoMHJnOHBiOG1ibDhyNTA=","response_type":"code","scope":"introscpect_tokens, revoke_tokens","iss":"bjhIRjM1cXpaa21zdWtISnp6ejlMbk44bTlNZjk3dXE=","sub":"YzEzMGdoMHJnOHBiOG1ibDhyNTA=","aud":"https://localhost:8443/{tid}/{aid}/oauth2/authorize","jti":"1516239022","exp":"2021-05-17T07:09:48.000+0545"}`;

console.log(hexy(dummyJwtPayload));

it prints:

00000000: 7b22 636c 6965 6e74 5f69 6422 3a22 597a  {"client_id":"Yz
00000010: 457a 4d47 646f 4d48 4a6e 4f48 4269 4f47  EzMGdoMHJnOHBiOG
00000020: 3169 6244 6879 4e54 413d 222c 2272 6573  1ibDhyNTA=","res
00000030: 706f 6e73 655f 7479 7065 223a 2263 6f64  ponse_type":"cod
00000040: 6522 2c22 7363 6f70 6522 3a22 696e 7472  e","scope":"intr
00000050: 6f73 6370 6563 745f 746f 6b65 6e73 2c20  oscpect_tokens, 
00000060: 7265 766f 6b65 5f74 6f6b 656e 7322 2c22  revoke_tokens","
00000070: 6973 7322 3a22 626a 6849 526a 4d31 6358  iss":"bjhIRjM1cX
00000080: 7061 6132 317a 6457 7449 536e 7036 656a  paa21zdWtISnp6ej
00000090: 6c4d 626b 3434 6254 6c4e 5a6a 6b33 6458  lMbk44bTlNZjk3dX
000000a0: 453d 222c 2273 7562 223a 2259 7a45 7a4d  E=","sub":"YzEzM
000000b0: 4764 6f4d 484a 6e4f 4842 694f 4731 6962  GdoMHJnOHBiOG1ib
000000c0: 4468 794e 5441 3d22 2c22 6175 6422 3a22  DhyNTA=","aud":"
000000d0: 6874 7470 733a 2f2f 6c6f 6361 6c68 6f73  https://localhos
000000e0: 743a 3834 3433 2f7b 7469 647d 2f7b 6169  t:8443/{tid}/{ai
000000f0: 647d 2f6f 6175 7468 322f 6175 7468 6f72  d}/oauth2/author
00000100: 697a 6522 2c22 6a74 6922 3a22 3135 3136  ize","jti":"1516
00000110: 3233 3930 3232 222c 2265 7870 223a 2232  239022","exp":"2
00000120: 3032 312d 3035 2d31 3754 3037 3a30 393a  021-05-17T07:09:
00000130: 3438 2e30 3030 2b30 3534 3522 007d         48.000+0545"}

Notice how the ASCII part of the last line (48.000+0545"}) is misaligned by a few characters.

I would expect it to look like this:

00000110: 3233 3930 3232 222c 2265 7870 223a 2232  239022","exp":"2
00000120: 3032 312d 3035 2d31 3754 3037 3a30 393a  021-05-17T07:09:
00000130: 3438 2e30 3030 2b30 3534 3522 007d       48.000+0545"}

[rm-hull]

Also - actually, I think this is what this issue is - is that the 007d is not correct, it should just be 7d - there are 13 bytes on the last row, but the hexdump implies 14 bytes.

So I would expect the last few lines to look like this instead:

00000110: 3233 3930 3232 222c 2265 7870 223a 2232  239022","exp":"2
00000120: 3032 312d 3035 2d31 3754 3037 3a30 393a  021-05-17T07:09:
00000130: 3438 2e30 3030 2b30 3534 3522 7d         48.000+0545"}

[a2800276]

Thanks for the issue!
I can reduce this down to a odd number of bytes in the final line ...

dummyJwtPayload2 =  `a`;
console.log(hexy.hexy(dummyJwtPayload2))

00000000: 0061                                       a

Are you debugging this btw?

[a2800276]

@rom-p would you mind having a quick look at this, and let me know if you have ideas concerning a fix? It' seems like this was introduced with your endianness and performance tuning changes, and I'm having a bit of trouble wrapping my head around it.

It looks to me like the the the "groups" (in this case of two bytes) are always treated as a unit, so a 2 byte group consisting of a single byte is considered incomplete and left padded with zero's. This would be ok when looking at a bunch of 16-bit values, but doesn't work out for individual bytes.

[rm-hull]

Also, the little-endian stuff doesn't work properly at all:

Try creating a file with: echo -n abc > test_file.txt, then using the view.html test page to tinker with it, and it just reports zeros for the different groupings:

[a2800276]

Yeah, I'm getting the feeling I jumped the gun with that merge request. I personally don't see the benefit in a hex viewer reformatting the order of the bytes. But the original contributor put a lot of effort into the patches and tests. If I don't hear from them I guess I'll throw the little endian stuff out.

It might take me a couple of days to clean things up. You can use version 0.3.2 if you're don't need little endian or anything crazy and want to avoid the issue...