[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120309083358.GA184@brightrain.aerifal.cx>
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.
