search

BLAKE3-team / BLAKE3

the official Rust and C implementations of the BLAKE3 cryptographic hash function
Apache License 2.0
5.02k stars 341 forks source link

fix blake3_neon.c on big-endian ARM #43

Open oconnor663 opened 4 years ago

oconnor663 commented 4 years ago

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 commented 4 years ago

Thank Kenneth Smith

On Sat, Jan 25, 2020, 4:14 PM oconnor663 notifications@github.com 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 https://github.com/BLAKE3-team/BLAKE3/issues/43?email_source=notifications&email_token=AOIFCG6HQ4J5L3FRTT3C64TQ7S2SZA5CNFSM4KLTKC2KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIW3I2A, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIFCG2X2L4U5UYSDCXFGBLQ7S2SZANCNFSM4KLTKC2A .

barracuda156 commented 2 months ago

Has this ever been addressed?