From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/628 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 0/4] Fix function definitions. Date: Fri, 9 Mar 2012 03:33:58 -0500 Message-ID: <20120309083358.GA184@brightrain.aerifal.cx> References: <1331280854-9080-1-git-send-email-gf@unixsol.org> <4F59BD70.9020105@unixsol.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1331282061 29408 80.91.229.3 (9 Mar 2012 08:34:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Mar 2012 08:34:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-629-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 09 09:34:19 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 1S5vHG-0002EQ-Vw for gllmg-musl@plane.gmane.org; Fri, 09 Mar 2012 09:34:19 +0100 Original-Received: (qmail 3957 invoked by uid 550); 9 Mar 2012 08:34:18 -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 3947 invoked from network); 9 Mar 2012 08:34:17 -0000 Content-Disposition: inline In-Reply-To: <4F59BD70.9020105@unixsol.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:628 Archived-At: 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