HOST_FILLORDER detection on non-x86 little-endian architectures
Summary
Libtiff configure sets HOST_FILLORDER to FILLORDER_MSB2LSB on aarch64 although it's a little-endian architecture.
Version
4.4.0 and master (as of 2023-05-06)
Steps to reproduce
Run configure/cmake on aarch64 Linux, install and check /usr/include/tiffconf-64.h:
grep HOST_FILLORDER /usr/include -r
Expected output:
/usr/include/tiffconf-64.h:#define HOST_FILLORDER FILLORDER_LSB2MSB
Actual output:
/usr/include/tiffconf-64.h:#define HOST_FILLORDER FILLORDER_MSB2LSB
Platform
Fedora 38 on aarch64 (a.k.a. arm 64 bit) However, issue isn't Fedora specific.
Additional information:
I don't see how any specific bit-order is advantageous on a given system. I mean, the bit order usually doesn't matter when programming in C (or even in assembler), in contrast to the byte-order. On modern architectures, bits aren't directly addressable, registers are loaded/copied as words and a - say - left-shift instruction yields the same result independent of some native bit-order that is usually unknown. Different compilers/platforms use different orderings in bit-fields, but this isn't really related to the 'native' bit-order.
Locations where the 'native' fill-order is detected:
https://gitlab.com/libtiff/libtiff/-/blob/9bd48f0dbd64fb94dc2b5b05238fde0bfdd4ff3f/configure.ac#L258 https://gitlab.com/libtiff/libtiff/-/blob/9bd48f0dbd64fb94dc2b5b05238fde0bfdd4ff3f/cmake/ProcessorChecks.cmake#L30