[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jul 2011 21:03:29 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: cluts review
Luka,
On Wed, Jul 13, 2011 at 06:25:51PM +0200, Luka Mar??eti?? wrote:
> >>- act.sa_flags = SA_NODEFER;
> >>+ act.sa_flags = 0;
> >This was being used as part of the longjmp trick.
>
> Can you remind me what this does exactly? I can't remember anymore,
> seemed to me it really was not needed. man says so as to not prevent the
> signal handler from (paraphrasing:) calling a signal itself. I don't
> need this, but you probably suggested it for some other reason then.
> Please do remind me. Thanks.
As Rich reminded me (in here), this was needed to keep the signal
unblocked even after longjmp() back into your main program. Otherwise,
the kernel blocks the signal when calling the signal handler, the signal
handler longjmp()s (doesn't return), and the signal remains blocked.
My recommended fix is to keep sa_flags at 0 (as changed above), but to
switch to using sigjmp_buf/sigsetjmp/siglongjmp.
> >By the way, there are a lot of warnings about local vars potentially
> >clobbered by longjmp. Those are worth checking out. I found gcc was
> >pretty strict about breaking my code in the dynamic linker when I
> >broke the rules for longjmp...
>
> These result from the -02 parameter.
This doesn't mean that they are harmless. It only means that gcc
doesn't always see the problems.
Do you understand what clobbering by longjmp means and why it occurs?
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.
