Sigactions and innfeed

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> I was wandering in innfeed/endpoint.c when I saw that there are
> references to:
>     #if defined(USE_SIGACTION)
> and:
>     #ifndef HAVE_SIGACTION
>
> but I do not see such variables in my configure.  Are there
> architectures which define them?  Is it sure that there are both USE_*
> and HAVE_*?

Wow, that's a long-standing bug.  I bet this has been broken since we
converted to Autoconf.

The innfeed code was written to handle any of sigaction, sigblock, or
sighold.  sigblock is the historic BSD signal code, and sighold is the
historic System V signal code.  However, the rest of INN just uses
sigaction and then falls back on simple signal (which is in ISO C) because
it just cares about signal handlers.  innfeed is actually trying to block
signals, which is trickier and doesn't have an ISO C function.

Autoconf doesn't probe for anything but sigaction and doesn't set
USE_SIGACTION, which means that in practice we've not been compiling any
of that code and have not been blocking signals.

sigaction is required by POSIX, so I doubt we really need to care about
systems that don't have it at this point.  I just cleaned up this code in
CURRENT to remove the historic BSD and System V code paths.

> By the way, do you think innfeed was broken on every 64bit architecture
> because of sig_atomic_t being long and not int?  It is strange that
> there more people had not reported such a problem...

I think it's more common to have sig_atomic_t be int even on 64-bit
platforms.  glibc unconditionally defines it to be an int, for instance.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.