[Toybox] [musl] [PATCH 0/4] Fix function definitions.

[Georgi Chorbadzhiyski]

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/