On Tue, Feb 21, 2012 at 05:28:22PM -0800, Philip Guenther wrote: > On Tue, 21 Feb 2012, Woodchuck wrote: > > >Synopsis: /usr/include/sys/param.h breaks code > > >Category: system > > >Environment: > > System : OpenBSD 5.0 > > Details : OpenBSD 5.0-stable (GENERIC.MP) #0: Thu Feb 16 01:38:28 > > EST 2012 > > > > [email protected]:/usr/src/sys/arch/i386/compile/GENERIC.MP > > > > Architecture: OpenBSD.i386 > > Machine : i386 > > >Description: > > /usr/include/sys/param.h contains a "convenience macro" named > > nitems, which causes user code using nitems in an innocent > > context to fail mysteriously. The bug was spotted during > > compilation of c++ code that uses the FLTK port. > > Whether this is a bug depends, IMO, on how <sys/param.h> is getting pulled > in. > > It's a bug that <netdb.h> unconditionally pulls in <sys/param.h>. It > should not, at least not in a standards conforming compilation mode. If > that's how it's getting pulled into this program, then I agree it's a bug > in the OpenBSD headers. > > > If the application code itself is #including <sys/param.h> itself, well, > it's getting exactly what it asked for. That file is *not* standardized > and may contain whatever the platform feels like, including a macro named > nitems(). > > (Code that pulls in header files "just in case" (or worse, "just because > it's present on this system"!) is Just Plain Wrong.) >
Code that tries to be portable and needs the BYTE_ORDER macro (or alike) has no other choice than including sys/param.h, does it? -- Alexandre
