Stream: API design

Topic: preventing endianness leaks

Richard Feldman (Jun 09 2024 at 14:26):

splitting off from this:

Brendan Hansknecht said:

If you have the bytes [ 0x00, 0x00, 0x00, 0x07 ] as your 32 bit big endian number input, you do:

when bytes is
    [b3, b2, b1, b0, ..] ->
        num = (b3 << 24) |  (b3 << 16) |  (b3 << 8) |  b3

Now num is whatever native endian happens to be

Richard Feldman (Jun 09 2024 at 14:27):

this is unfortunate because it breaks the design goal of “Roc code gives the same answer no matter what target it’s run on”

Richard Feldman (Jun 09 2024 at 14:27):

I wonder how we can fix this without hurting performance

Richard Feldman (Jun 09 2024 at 14:40):

:thinking: actually, is the bit shifting the problem? Or is it that integer byte order can be observed at all without specifying endianness?

timotree (Jun 09 2024 at 15:21):

I don't think bit shifting is giving a different answer depending on endianness here. num will be the same integer on any target, it's just that its unobservable in-memory representation will depend on the target

Brendan Hansknecht (Jun 09 2024 at 16:14):

Oh, missed this thread, this is not an issue

Brendan Hansknecht (Jun 09 2024 at 16:14):

I am explicitly receiving the bytes in big endian and then mapping them to a native endian integer. It does not exposed what native endian is

Brendan Hansknecht (Jun 09 2024 at 16:15):

And this is how to map little to native:

when bytes is
    [b0, b1, b2, b3, ..] ->
        num = (b3 << 24) |  (b3 << 16) |  (b3 << 8) |  b3

Richard Feldman (Jun 09 2024 at 19:53):

oh interesting - so it’s a way to go to native but then once it’s in native, nothing about native can leak?

Brendan Hansknecht (Jun 09 2024 at 20:05):

yeah

Last updated: Jul 06 2025 at 12:14 UTC