> Date: Sun, 31 Mar 2013 00:16:16 -0700 > From: Philip Guenther <guent...@sendmail.com> > > On Sat, 30 Mar 2013, Andres Perera wrote: > > freebsd has _null.h > > ...but their sys/queue.h doesn't include it. > > There are two questions here: > 1) should <sys/queue.h> be standalone or does it require NULL to be > defined separately? > 2) if the latter, what should the manpage say? > > Currently, FreeBSD and OpenBSD agree about (1): some <sys/queue.h> macros > require NULL to be defined before they are used but the header does not > define itself define NULL.
Neither do OS X and Linux. NetBSD really seems to be the odd one out here. > Regarding (2): an internal header like their <sys/_null.h> should never be > included directly by an application, so it certainly doesn't belong in the > manpage. That leaves three options: > > a) document in queue(3) that some macros may require NULL to be defined > b) make <sys/queue.h> define NULL > c) stop using NULL in sys/queue.h In a BSD world the answer is a) and the way to document it would be to add an "#include <sys/types.h>" to the SYNPOSIS. It was already pointed out that <sys/types.h> doesn't always define NULL, but frankly, what the hell are you doing if you compile with -D_POSIX_SOURCE but include non-POSIX stuff like <sys/queue.h>. But I guess we could add some text that suggest to include <sys/types.h> or <stddef.h>. b) would encourage writing unportable code. But it would probably make things a littlew bit easier for the ports people. c) wouldn't be terribly helpful either. The examples in queue(3) use NULL. It explicitly documents SLIST_END(), LIST_END(), SIMPLEQ_END() and TAILQ_END() macros as explanding to NULL. And on top of that getting something like NULL right for C++ takes some effort. So my vote goes to a).
