[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jul 2011 18:46:11 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: cluts review
On Wed, Jul 13, 2011 at 10:26:03AM -0400, Rich Felker wrote:
> cat <<EOF >test.c
> #define _XOPEN_SOURCE 700
> #include <limits.h>
> PATH_MAX
> EOF
> gcc -E test.c | tail -n 1
Yeah, it works for me too. It's just that in cluts.c, after all those
other #include's and with no feature test macros defined at all,
<limits.h> wouldn't provide PATH_MAX. Somehow <limits.h> on its
own, also with no feature test macros at all, does provide PATH_MAX.
Anyhow, I am not going to investigate further. It is clear that when we
do request at least _BSD_SOURCE or _XOPEN_SOURCE, then <limits.h> does
give us PATH_MAX.
> > > > - 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.
Oh, you're right, and my comment above re: "keep the signal blocked"
didn't make sense (it's the other way around).
> 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...
I think that we need to switch to using sigsetjmp/siglongjmp as I had
suggested before.
Alexander
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.
