Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 6 Apr 2012 22:47:40 -0700
From: Isaac Dunham <>
Subject: Re: [PATCH] _BSD_SOURCE for unistd.h, take 2

> > Still, I tend to prefer having some respect for even unofficial
> > namespaces.
> A more general issue: this patch addresses _BSD_SOURCE enabling the
> nonstandard functions, but what should the behavior of _BSD_SOURCE be
> with regards to functions that are in XSI but not POSIX base? My
> inclination is to make it so _BSD_SOURCE implies _XOPEN_SOURCE and
> _POSIX_C_SOURCE everywhere (i.e. add it to all the big || lists in all
> the headers) unless there's a strong argument against doing this. As
> it stands, defining just _BSD_SOURCE but not _POSIX_C_SOURCE or
> _XOPEN_SOURCE would leave you with a fairly broken set of headers, I
> think..

There seemed to be large numbers of functions that were _XOPEN_SOURCE
but not _BSD_SOURCE, if I'm remembering right.  It seemed to mostly
fall somewhere between *old* X/Open and POSIX, with some extensions;
it definitely should imply POSIX, but I'd avoid *automatically* adding
X/Open (see previous comment about respecting nonstandard namespaces).
It would be annoying to write a program, use -D_BSD_SOURCE, have it
work, move to another libc, and have to change CFLAGS--especially if
that's because of disregard for the namespace. 

In some places assuming _XOPEN_SOURCE would be appropriate; we should
look at each case. 

Isaac Dunham

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.