From owner-freebsd-bugs Thu Oct 3 1:50:12 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24DC037B404 for ; Thu, 3 Oct 2002 01:50:11 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB9B43E42 for ; Thu, 3 Oct 2002 01:50:10 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA23918; Thu, 3 Oct 2002 18:05:35 +1000 Date: Thu, 3 Oct 2002 18:15:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Gregory Bond Cc: "Jin Guojun [DSD]" , Garrett Wollman , Subject: Re: kern/43599: Balloc did not check mallocated pointer in libc/stdlib/strtod.c In-Reply-To: <200210030033.KAA01121@lightning.itga.com.au> Message-ID: <20021003180049.Q2910-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 3 Oct 2002, Gregory Bond wrote: > For FreeBSD, signal(3) contains the sentence: > > See sigaction(2) for a list of functions that are considered safe for use > in signal handlers. > > And sigaction(2) has a list of 40-50 system calls and functions [notably _not_ > including any STDIO ones, or longjmp()] and the comment: > > All functions not in the above lists are considered to be unsafe with > respect to signals. That is to say, the behaviour of such functions when > called from a signal handler is undefined. This bug shows that even sprintf() is unsafe to use in signal handlers, although using it to work around the unsafeness of fprintf seems to be fairly common (n = sprintf(buf, ...); if (n > 0) write(2, buf, n); else ..."). Another problem is that floating point might not work in signal handlers; (it was broken under FreeBSD on i386's until the recent ucontext changes), so calling strtod() from signal handlers was unsafe in practice. strtod(), not to mention simpler functions like strlen() isn't in the list in sigaction(2) (or in the corresponding list in POSIX IIRC), so calling it from signal handlers is unsafe in theory. It's not clear that there is any standard && useful use for floating point in signal handlers. Standards seem to require things like "double x, y; x = 2; y = x + x;" to work, but they don't provide any way for the results to affect the world outside of the signal handler except in the unlikely event that sig_atomic_t is floating point, and except for silly things like encoding the results of floating point operations in variables of type sig_atomic_t. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message