Re: [PATCH] Reset the terminal state if we are killed by a fatal signal.

[Mike Frysinger <vapier@xxxxxxxxxx>]

On Monday 07 April 2008, James Youngman wrote:
> On Tue, Apr 8, 2008 at 12:38 AM, Karel Zak <kzak@xxxxxxxxxx> wrote:
> > On Sun, Apr 06, 2008 at 12:15:46PM +0100, James Youngman wrote:
> >  > -static struct termios termios;
> >  > -static int termios_set = 0;
> >  > +static volatile struct termios termios;
> >
> >   Do we really need "volatile" here?
>
> The code may never be run on a system where it actually makes a
> difference.   So I guess we can do without it - and especially so
> since it causes compilation errors.

where would it make a difference ?  the settings we care about are written 
once by the libc where volatile markings are irrelevant, and that pointer is 
then read in the signal handler.

> >  > +static void
> >  > +fatalsig(int sig) {
> >  > +     /* We received a fatal signal.  Reset the terminal.
> >  > +      * Also reset the signal handler and re-send the signal,
> >  > +      * so that the parent process knows which signal actually
> >  > +      * caused our death.
> >  > +      */
> >  > +     signal(sig, SIG_DFL);
> >
> >   You needn't to reset the handler to SIG_DFL. That's default behaviour
> >   when you define the handler by signal(2).
>
> It's not something you can portably rely on; better safe than sorry.
> From the signal(2) manpage on my system:
>
>    Portability
>        The original Unix signal() would reset the handler to SIG_DFL, and
> Sys‐ tem V (and the Linux kernel and libc4,5) does the same.  On  the 
> other hand,  BSD does not reset the handler, but blocks new instances of
> this signal from occurring during a call of the handler.  The glibc2
> library follows the BSD behavior.

if you're worried about portability, you should be using sigaction().  
otherwise, use of signal() should really assume Linux semantics.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.