On Mon, Oct 13, 2014 at 5:26 AM, David Gwynne <da...@gwynne.id.au> wrote: > On 13 Oct 2014, at 9:00 pm, Christian Weisgerber <na...@mips.inka.de> wrote: > >> David Gwynne: >> >>> dont you need endian.h to get bemtoh64 and htobem64?
(This is kernel code, so that would be <sys/endian.h>) >> I went by the man page, which says <sys/types.h>. > > and cvs blame says that's my fault... fair enough. > > ill talk to philip about whether that should change, but dont let that hold > the process up on this code. Well. Right now <sys/types.h> pulls in <sys/endian.h> (or at least <sys/_endian.h>); someone with lots of patience and many archs to test on could try removing that (and making <sys/types.h> pull in <sys/_types.h> directly!) and see how many .c files would need to change and, more importantly, how badly ports break. Until then, I see little benefit for kernel code to pull in <sys/endian.h>; you'll get it indirectly after pulling in <sys/types.h> or <sys/param.h>, so it's just noise and wasted compiler cycles. The manpages for the kernel-only interfaces (bemtoh*, etc) should presumably follow that: recommending sys/types.h until someone removes the indirect #include. Philip Guenther
