From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/630 Path: news.gmane.org!not-for-mail From: Georgi Chorbadzhiyski Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 0/4] Fix function definitions. Date: Fri, 09 Mar 2012 11:16:00 +0200 Message-ID: <4F59CA50.5060407@unixsol.org> References: <1331280854-9080-1-git-send-email-gf@unixsol.org> <4F59BD70.9020105@unixsol.org> <20120309083358.GA184@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1331284577 14760 80.91.229.3 (9 Mar 2012 09:16:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Mar 2012 09:16:17 +0000 (UTC) Cc: Rich Felker , Rob Landley , toybox@lists.landley.net To: musl@lists.openwall.com Original-X-From: musl-return-631-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 09 10:16:14 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1S5vvp-0007Ye-Tq for gllmg-musl@plane.gmane.org; Fri, 09 Mar 2012 10:16:14 +0100 Original-Received: (qmail 7857 invoked by uid 550); 9 Mar 2012 09:16:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7849 invoked from network); 9 Mar 2012 09:16:12 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: <20120309083358.GA184@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:630 Archived-At: 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/