[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110713142603.GF16618@brightrain.aerifal.cx>
Date: Wed, 13 Jul 2011 10:26:03 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: cluts review
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 <<EOF >test.c
#define _XOPEN_SOURCE 700
#include <limits.h>
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 <sys/param.h>
#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
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.
