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.
