From owner-freebsd-bugs  Wed Jan  1 18:01:31 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id SAA08210
          for bugs-outgoing; Wed, 1 Jan 1997 18:01:31 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA08204
          for <freebsd-bugs@freefall.freebsd.org>; Wed, 1 Jan 1997 18:01:27 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id MAA20387; Thu, 2 Jan 1997 12:51:43 +1100
Date: Thu, 2 Jan 1997 12:51:43 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199701020151.MAA20387@godzilla.zeta.org.au>
To: freebsd-bugs@freefall.freebsd.org, wollman@lcs.mit.edu
Subject: Re: bin/2347: sysinstall: ppp: recursive call in malloc()
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >  I'm not definitively sure what POSIX & friends say about the reentrancy
> >  of malloc(3) but I belive it is not required to be reentrant.
>  
> >  Anybody know definitively what POSIX say here ?
>  
> Well, I can't tell you what POSIX says, but I can tell you what ANSI
> X3J11 said: the only thing you can do inside a signal handler is set a
> variable of type `volatile sig_atomic_t'.

POSIX doesn't allow it either of course.

POSIX does allow calling many syscalls.  FreeBSD seems to be broken
here.  The global variable `errno' may be clobbered by any syscall.

There is an upen PR about floating point being available in signal
handlers.  The user wants to call printf(), which can't be expected
to work.  Unfortunately, even ANSI requires floating point to work
right in signal handlers, because it allows normal operations on
auto variables.  The variables might be floating point, and even
though you can't print them, you can do things like

	volatile double dfoo = 1.0, dbar = 3.0;
	volatile float  ffoo = 1.0, fbar = 3.0;
	extern volatile sig_atomic_t baz;
	baz = (dfoo / dbar = ffoo / fbar);

which probably requires runtime floating point no matter what the
optimization level is.

> Hearsay: one of the UNIX standards (maybe P1003.n, maybe XPGn, maybe
> Spec 1170) specifies a list of *system calls* which may be called from
> signal handlers.  I think one or more of them may also require that
> longjmp() work from a signal handler, but not necessarily that
> anything work after doing that.

POSIX.1 doesn't require longjmp() to work right.  It requires simple
syscalls like read() and write() to work right.  It is under-specified
in not saying much about side effects like read() to global memory
clobbering the memory.  It requires non-simple things like fork() and
execve() to work right.  It requires not-so-simple things that are
implemented as library functions in FreeBSD to work right.  Some of
them can't possibly be POSIX conformant.  E.g., sleep() is very far
from being atomic.

longjmp() works right in FreeBSD - calling it from a signal handler
is no worse than calling it from a random point in the program or
library.  Even a random non-sequence point, I hope.

Bruce