Re: [PATCH 0/4] Fix function definitions.

[Rich Felker <dalias@aerifal.cx>]

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