Date: Fri, 9 Mar 2012 03:33:58 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: [PATCH 0/4] Fix function definitions. 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... > 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". 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.