Re: [rfc] posix.4 signals implementation

Trevor Johnson (trevor@jpj.net)
Fri, 16 May 1997 02:28:32 +0000 (Local time zone must be set--see zic manual pagtrevor@jpj.net

> While people are discussing posix signals I'd just like to point out again
> that the 2.0 -> 2.0.1 changes for signal handling broke various binaries.
> For example, to get a working bash (I don't think any distributions do
> this) you have to -DBROKEN_WAITPID while building it. Here is an example
> where it fails:
>
> cat >bad <<EOF
> #!/bin/sh
> ed $*
> EOF
> chmod +x bad
> ./bad bad
>
> Now ^Z and fg that repeatedly. Eventually you'll hit a race condition
> causing bash to exit and leave ed lying around. If you don't like ed,
> replace it with vi (elvis or vim).

I brought it to the foreground 62 times using ed, and 63 times with vi,
but didn't see the problem. I know that doesn't prove there is no
problem. I have:

bash 2.00.0(1)-release, linked with glibc 2.0.3 and libtermcap 2.0.8
GNU ed 0.2
nvi 1.79
Linux pre-2.0.31

When I ran the configure script, it gave these messages (among others):
checking return type of signal handlers... void
checking for siginterrupt... yes
checking for sys_siglist declaration in signal.h or unistd.h... yes
checking return type of signal handlers... (cached) void
checking for sys_siglist in system C library... yes
checking for _sys_siglist in system C library... no
checking for type of signal functions... posix
checking whether signal handlers are of type void... yes
checking for sigset_t... yes
checking for the existance of strsignal... yes
checking for presence of POSIX-style sigsetjmp/siglongjmp... present
checking if signal handlers must be reinstalled when invoked... no
checking for wait3 that fills in rusage... yes
checking for wait3... yes
checking for waitpid... yes
checking for sys/wait.h... yes

It didn't put any mention of WAITPID into any of the makefiles.
___
Trevor Johnson <trevor@jpj.net>