Date: Fri, 09 Mar 2012 11:16:00 +0200 From: Georgi Chorbadzhiyski <gf@...xsol.org> To: musl@...ts.openwall.com CC: Rich Felker <dalias@...ifal.cx>, Rob Landley <rob@...dley.net>, toybox@...ts.landley.net Subject: Re: [PATCH 0/4] Fix function definitions. On 3/9/12 10:33 AM, Rich Felker wrote: > On Fri, Mar 09, 2012 at 10:21:04AM +0200, Georgi Chorbadzhiyski wrote: >> Subject: Re: [musl] [PATCH 0/4] Fix function definitions. > > I think you mean declarations. :-) > >> Hmm...it seems this is not enough. See include/unistd.h >> >> #ifdef _GNU_SOURCE >> int brk(void *); >> void *sbrk(intptr_t); >> pid_t forkall(void); >> int vhangup(void); >> int getpagesize(void); >> int usleep(unsigned); >> unsigned ualarm(unsigned, unsigned); >> int setgroups(size_t, const gid_t ); >> int setresuid(uid_t, uid_t, uid_t); >> int setresgid(gid_t, gid_t, gid_t); >> char *get_current_dir_name(void); >> #endif >> >> Most of the above according to their man pages should be defined if >> _BSD_SOURCE is set. > > At present musl makes no attempt to support(*) the _BSD_SOURCE or > _SVID_SOURCE feature test macros; every nonstandard (non-POSIX) > extention offered by glibc is grouped together under _GNU_SOURCE, and > this works for musl because (unlike with glibc), musl's _GNU_SOURCE > only enables features; it does not alter standard interfaces like > strerror_r or basename to be broken GNU versions of the functions. > > I think there's a good (nontrivial) discussion to be had about whether > it's worthwhile to have the _BSD_SOURCE and _SVID_SOURCE feature test > macros supported in musl. The main benefit I can see is that > applications which define _BSD_SOURCE or _SVID_SOURCE in their default > CFLAGS for the sake of getting certain important traditional > interfaces (like MAP_ANONYMOUS) but without bringing in broken GNU > behavior could perhaps be made to work out-of-the-box on musl without > manually adding -D_GNU_SOURCE to the CFLAGS. On the other hand, since > musl's _GNU_SOURCE is "non-destructive", I'm not sure that's a huge > benefit. > > (*) _BSD_SOURCE appears in some places in musl's headers now, but that > was due to a (rather ill-thought-out) attempt to add some BSD > functions like strlcpy which glibc refuses to support, and avoid > making them visible when just _GNU_SOURCE is used. I'm largely > convinced this approach was a mistake, but how it should work is still > a topic for discussion... Umm, like I expected all those declarations open a big can of worms :( >> Should the headers be filled with feature checks (that would make them >> quite ugly) or assume we have _GNU_SOURCE defined and remove any _GNU_SOURCE >> checks? > > I'm confused what you mean by "assume we have _GNU_SOURCE defined". Well, ignore my suggestion. I was thinking of removing most _GNU_SOURCE checks in headers (except for pure GNU extensions) but reading what you wrote above I remembered what PITA feature_macros were. Unfortunately it seems that defining _GNU_SOURCE to get the kitchen sink is easier... -- Georgi Chorbadzhiyski http://georgi.unixsol.org/
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.