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.