From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/140 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: cluts review Date: Wed, 13 Jul 2011 10:26:03 -0400 Message-ID: <20110713142603.GF16618@brightrain.aerifal.cx> References: <20110713110723.GA22153@openwall.com> <20110713133838.GA16618@brightrain.aerifal.cx> <20110713141249.GA23314@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1310567733 16905 80.91.229.12 (13 Jul 2011 14:35:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 14:35:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-224-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 13 16:35:30 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Qh0XC-0007ww-0o for gllmg-musl@lo.gmane.org; Wed, 13 Jul 2011 16:35:30 +0200 Original-Received: (qmail 28232 invoked by uid 550); 13 Jul 2011 14:35:29 -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 28224 invoked from network); 13 Jul 2011 14:35:29 -0000 Content-Disposition: inline In-Reply-To: <20110713141249.GA23314@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:140 Archived-At: On Wed, Jul 13, 2011 at 06:12:49PM +0400, Solar Designer wrote: > > > +#define _BSD_SOURCE /* for scandir() and alphasort() */ > > > > These are POSIX 2008 functions. _BSD_SOURCE should not be needed for > > anything. > > Is it acceptable to require POSIX 2008? Don't we want cluts to build > and run on significantly older systems, which wouldn't know to define > these functions on -D_POSIX_C_SOURCE=200809L? Hmm. In this case also defining _BSD_SOURCE might be good, but I'm a bit worried about glibc behavior, which seems to be to *prefer* BSD or GNU variants over the standard version of some functions when the corresponding BSD/GNU feature test macros are defined... Not sure what the best solution is. > What specific feature test macros would you recommend for getting > PATH_MAX defined? This works for me (on glibc): cat <test.c #define _XOPEN_SOURCE 700 #include PATH_MAX EOF gcc -E test.c | tail -n 1 What system are you using that lacks it? One (mildly ugly) solution, if needed, would be: #ifndef PATH_MAX #include #endif > > > +#define _XOPEN_SOURCE /* for sigaction() */ > > > > Needs a value, not a blank definition. Current version is 700. > > So, your proposal is to always request the latest spec version. > Wouldn't it possibly be better to request the oldest sufficient for us? My theory is that implementations will silently drop back to giving you an older version (and informing you in _XOPEN_VERSION) if they can't provide the version you request. I believe this is true in practice but I'm not 100% sure. I just prefer doing things that way to trying to remember exactly what changed in each version of the standard and which version is actually the "oldest sufficient". > > > - act.sa_flags = SA_NODEFER; > > > + act.sa_flags = 0; > > > > This was being used as part of the longjmp trick. > > Why, how? Did we seriously want to keep the signal blocked? It's to leave the signal unblocked so that longjmp can return without having to restore the signal mask. It might be slightly more portable to just manually unblock it or use sigsetjmp/siglongjmp to do so, but unless I'm mistaken the last system with broken SA_NODEFER was Linux 1.3 or so... Rich