fix blake3_neon.c on big-endian ARM

[oconnor663]

The current implementations of loadu_128 and storeu_128 use memcpy to read uint32x4_t vectors of e.g. hash input, which implicitly assumes the machine byte order is little-endian. My understanding is that that's true of most but not all ARM devices. We should figure out how to either make the code endianness-independent, or how to produce a compile-time error on big-endian ARM.

[Trendsetter74]

Thank Kenneth Smith

…

On Sat, Jan 25, 2020, 4:14 PM oconnor663 ***@***.***> wrote: The current implementations of loadu_128 and storeu_128 use memcpy to read uint32x4_t vectors of e.g. hash input, which implicitly assumes the machine byte order is little-endian. My understanding is that that's true of most but not all ARM devices. We should figure out how to either make the code endianness-independent, or how to produce a compile-time error on big-endian ARM. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43?email_source=notifications&email_token=AOIFCG6HQ4J5L3FRTT3C64TQ7S2SZA5CNFSM4KLTKC2KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIW3I2A>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOIFCG2X2L4U5UYSDCXFGBLQ7S2SZANCNFSM4KLTKC2A> .