Comment by murderfs
1 day ago
> Those are contradictory. Either the code is extremely portable, or it can't support "obscure" platforms, but not both.
I think it's perfectly valid to call code 'extremely portable' without supporting every special snowflake architecture. There's a spectrum from assumptions that hold on everything that isn't some esoteric joke architecture or archaeology to something that I would probably consider required for 'extremely portable'.
I would personally consider something that failed to support anything on this list above big endian as still being extremely portable: you'll build for any serious modern architecture that isn't a DSP.
- non twos complement integers
- (int) nullptr != 0
- segmented addressing
- non-8 bit char
- big endian
- missing floating point
ARM's done a good job of making it so that you can't assume the traditional x86 assumptions of being able to access any pointer unaligned or having sequentially consistent semantics on memory ordering (with the help of compilers getting better at reordering resulting in you needing to have proper semantics on x86 as well).
It makes liberal use of u64 all over the place rather than a more appropriate, machine adaptive unsigned int or unsigned long. It isn't a good fit for anything "exotic" like non-64-bit platforms. I wouldn't consider that in the spirit of portability when it compiles into bloated code with unnecessarily large structs.
I was making a general point about portability, not this library in particular. I wouldn't consider "only x86_64 and aarch64" as being "portable".