Date: Tue, 12 Apr 2011 12:49:18 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: [compatibility] heirloom tools On Tue, Apr 12, 2011 at 06:35:51PM +0200, Christian Neukirchen wrote: > Rich Felker <dalias@...ifal.cx> 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? Rich
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.