Date: Thu, 2 Jan 1997 12:51:43 +1100 From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@freefall.freebsd.org, wollman@lcs.mit.edu Subject: Re: bin/2347: sysinstall: ppp: recursive call in malloc() Message-ID: <199701020151.MAA20387@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701020151.MAA20387>