Hi Bruno, On 5/13/24 5:38 AM, Bruno Haible wrote: >> 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.
Sounds good. I was working on tests at the same time but left it out of the patch. > 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]. Ah, okay. I was thinking it was mostly unused. > 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.) Interesting link. Yes, I guess it is a strange ordering. I didn't think about it to much. The POSIX draft has function prototypes in that order, so I just transformed them into macros. > 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); Ah, I forgot that I have to worry about it. Thanks for the tip. I was using stdint_h.m4 and sys_time_h.m4 to write that m4 file. Collin
