opack: fix byte encoding length

[thiccaxe]

#2403 (comment)

[postlund]

I'm not sure this is correct, I will have to verify with macOS implementation first.

[postlund]

Nope, you are correct 👍

postlund@Pierre ~ % echo 94010000000000000001 | xxd -r -p | ./decode
2024-08-07 19:48:34.307 decode[12510:963399] Decoded: {length = 1, bytes = 0x01}

Please update the documentation to reflect this as well.

[thiccaxe]

@postlund, I took a look at the docs, and realized that the same might apply to strings and pointers as well.

I think pointers would be hard to test, and I think either way no one will run into a 32 bit or 64 bit pointer... At least strings, though, can you test?

[postlund]

@postlund, I took a look at the docs, and realized that the same might apply to strings and pointers as well.

I think pointers would be hard to test, and I think either way no one will run into a 32 bit or 64 bit pointer... At least strings, though, can you test?

You are probably right. I'll see if I can try it out. Even if we use a large pointer since, we can still put a small value in the actual payload. So it's not much harder to test than smaller values.

[thiccaxe]

Any update?

[postlund]

Any update?

I'll merge it if you update the documentation related to your changes 👍

[thiccaxe]

I was actually wondering if you had been able to test strings or pointers for the similar length behavior.

[postlund]

Ah, right. I'll see if I can do that.

[postlund]

So, I used my example from the documentation but added an additional element at the end to ensure the pointer is somewhere inside the payload (I added 0=1 to the dict). It looks like this:

echo E4416102416244746573744163A20809 | xxd -r -p | ./decode
2024-09-09 20:02:52.341 decode[73452:3341836] Decoded: {
    0 = 1;
    b = test;
    c = test;
    a = 0;
}

The idea is now to change the pointer for the c key from A2 to something like C4 whilst maintaining the same result as above. Based on the documentation I already have, it should be C4 02 00 00 00. So let's try that:

echo E4416102416244746573744163C4020000000809 | xxd -r -p | ./decode
2024-09-09 20:05:01.990 decode[73483:3343621] Decoded: {
    0 = 1;
    b = test;
    c = test;
    a = 0;
}

So I would say current documentation is correct (although, I see now that C2 Is mentioned twice...). It makes sense for pointers as pointers are just indices and not raw byte position in the payload.