Hi Collin,
> Let me know if I missed anything. Other than the docs and test module
> which I can do later today (assuming this patch is decent enough).
The doc changes belong in the same commit. The tests module should be
in a different commit, but it's a good idea to develop both together,
since the tests often uncover problems.
> POSIX
> doesn't require PDP_ENDIAN and I would rather not think about it. :)
But glibc defines PDP_ENDIAN in <endian.h>, and Gnulib attempts to be
compliant to POSIX _and_ source-compatible with glibc.
Also there is some code that uses PDP_ENDIAN [1].
Why do you mention the functions in this order?
+/* Big endian to host. */
+/* Host to big endian. */
+/* Host to little endian. */
+/* Little endian to host. */
Doing things backwards in the second half than in the first half is
quite unusual; it's a particular property of the Morse sequence [2].
(Note that alphabetical order of items is only to be used as a fallback,
when items cannot be ordered by some form of logic or heuristic.)
In the autoconf test, compilation with -Wall would produce warnings about
the 12 unused variables. If a user sets CC="gcc -Wall -Werror", this will
make the compilation fail. Although this setting of CC is not supported by
Gnulib, it does not hurt to make things work in this case. Like done in
m4/intmax_t.m4: Add a 'return' statement that uses all the variables.
Such as
return !(value16_1 + value32_1 + value64_1 + value16_2 + value32_2 + value64_2
+ value16_3 + value32_3 + value64_3 + value16_4 + value32_4 +
value64_4);
Other than that, it looks fine.
Bruno
[1]
https://codesearch.debian.net/search?q=%5CbPDP_ENDIAN%5Cb+-path%3Aendian.h&literal=0
[2] https://en.wikipedia.org/wiki/Thue%E2%80%93Morse_sequence
