Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Apr 2011 12:49:18 -0400
From: Rich Felker <>
Subject: Re: [compatibility] heirloom tools

On Tue, Apr 12, 2011 at 06:35:51PM +0200, Christian Neukirchen wrote:
> Rich Felker <> writes:
> >> test:	sed -i 's/S_IREAD/S_IRUSR/g;s/S_IWRITE/S_IWUSR/g;s/S_IEXEC/S_IXUSR/g;' test/test.c test/helper.c
> >
> > These legacy aliases can be added under _GNU_SOURCE... done.
> And _BSD_SOURCE, I guess.

I've been rather inconsistent in use of _BSD_SOURCE, and not sure I
want to support it at all. The idea was that I've included a few BSD
functions like lchmod and strlcpy which are NOT in glibc, so it didn't
make sense to put their prototypes under _GNU_SOURCE. But as it
stands, _BSD_SOURCE enables only these things, not all the other BSD
features that are under _GNU_SOURCE, which differs from every other
library's behavior and doesn't seem all that useful. And adding
"|| defined(_BSD_SOURCE)" all over the place in all the headers seems
like just more clutter... I may just move all the BSD extensions under
_GNU_SOURCE anyway, even if they're not in glibc, and be done with it
- that way, a single feature test macro can enable all the "legacy and
nonstandard extension" functions.

Thoughts on if this is a good idea?


Powered by blists - more mailing lists

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