Re: endian.h / sys/types.h

[Greg Troxel <gdt%lexort.com@localhost>]

Patrick Welche <prlw1%welche.eu@localhost> writes:

> I was about to commit another pkgsrc fix: libpciaccess needing htole32
> (after nss, with xentools420 to go), but I just saw
>
> RCS file: /cvsroot/src/sys/sys/types.h,v
> ----------------------------
> revision 1.110
> date: 2026-01-12 14:51:50 +0000;  author: nia;  state: Exp;  lines: +2 -3;  commitid: ltgP8YLNsrBs67qG;
> Revert the change to stop including #include <sys/endian.h> from
> <sys/types.h>.
>
> This change was too risky in ways I didn't forsee, mostly that this code
> compiles fine without the header included:
>
> #if BYTE_ORDER == LITTLE_ENDIAN
> /* do little endian stuff */
> #else
> /* do big endian stuff */
> #endif
>
> ... then uses the big endian path on little endian machines.
>
> If strict POSIX mode is requested, we can avoid including it. The problem
> of relying on endian header transclusion is rare in non-BSD codebases.
> ----------------------------
>
> so, e.g., revert the nss fix (minimises diff with upstream), or keep
> going in the sense that the change is "correct"?


POSIX does not specify or even hint that endian.h should be
automatically included when including sys/types.h.   So the upstream
code has a bug, regardless of whether NetBSD conforms to POSIX by not
including endian, whether it's non-conformant, and whether it will
conform again.

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html

So I say fix it and in theory file a bug upstream.