From owner-freebsd-current@FreeBSD.ORG Wed May 28 13:45:31 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7438D37B401 for ; Wed, 28 May 2003 13:45:31 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CC1A43F85 for ; Wed, 28 May 2003 13:45:30 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id GAA31895; Thu, 29 May 2003 06:45:18 +1000 Date: Thu, 29 May 2003 06:45:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Polstra In-Reply-To: <200305281616.h4SGGLKI070255@strings.polstra.com> Message-ID: <20030529062255.Q2448@gamplex.bde.org> References: <200305201025.30296.jlido@goof.com> <20030527200208.L1802@gamplex.bde.org> <20030529011400.A1228@gamplex.bde.org> <200305281616.h4SGGLKI070255@strings.polstra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: gcc/libm floating-point bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 20:45:32 -0000 On Wed, 28 May 2003, John Polstra wrote: > In article <20030529011400.A1228@gamplex.bde.org>, > Bruce Evans 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