Re: gcc/libm floating-point bug?

On Wed, 28 May 2003, John Polstra wrote:

> In article <20030529011400.A1228_at_gamplex.bde.org>,
> Bruce Evans  <bde_at_zeta.org.au> wrote:
> > On Tue, 27 May 2003, Terry Lambert wrote:
> >
> > > BTW: signal stacks are irrelevent; technically, you are not
> > > allowed to do floating point in signal handlers anyway.  8-).
> >
> > Not true.  Signal handlers can do almost anything with local variables.
> > The main relevant restrictions on them is that they must not access
> > any static or global variables (other than write-only accesses to
> > objects whose type is volatile sig_atomic_t) or call any functions
> > that might make such accesses (which rules out calling most functions
> > including everything in libm).
>
> Those are the rules set forth by the C standard, but POSIX.1 demands
> much more from the implementation.  There's a whole list of functions
> that POSIX says must be safely callable from signal handlers.  Almost
> all of the I/O calls are included.  Even fork and exec[lv]e must be
> callable from signal handlers.

Not much more.  The list of signal-safe functions is relatively small
and doesn't contain much more than things that are usually implemented
as syscalls.  Syscalls don't access any static or global objects
except errno (*) unless they take a pointer arg and you point at a
static or global.  Obviously, you must not do that.  But POSIX seems
to be a little broken here.  From draft7:

%%%
1327                              The following table defines a set of functions that shall be either reentrant or non-
1328                              interruptible by signals and shall be async-signal-safe. Therefore applications may
1329                              invoke them, without restriction, from signal-catching functions:                             |
                                               !!!!!!!!!!!!!!!!!!!

1330                              _Exit( )              fpathconf( )               raise( )          sigprocmask( )             |||
1331                              _exit( )              fstat( )                   read( )           sigqueue( )
%%%

Unless there is some special wording elswhere, a literal reading of this
says that clobbering of static and global objects, e.g. by read()ing into
them, is harmless in signal handlers.

(*) POSIX seems to require the implementation to preserve errno in
signal handlers, since most of the signal-safe functions can set errno
and the "without restriction" clause says that the application code
for signal handlers doesn't need to preserve it (and signal handlers
obviously must preserve errno if they return).  I've never seen an
implementation that preserves it.  I've seen 0% of implementations
and epsilon% of application signal handlers preserving it.

Bruce