> Specifically, it depends on sigismember to return a 0 when the signal
> number goes over the number of bits in the datatype of set. i.e. 32
> bits in our case. The CVS code was using a loop with sigismember
> that went from 1 to whenever sigismember returned 0. sigismember never
> returned 0 on x86 1.0 beta and kept going and going like the
> Energizer bunny...
This argument has happened several times before, see the mailing list
archives...
Basically, the output of sigismember() is only defined if the signal
number is valid, and an error has to be returned only if an error
is detected. So if the number is invalid, and that's not detected
(and nothing says that it has to be), the result returned may not
be what's expected.
CVS isn't behaving in a POSIX-friendly manner, given its usage
of sigismember(). (of course, our sigismember() could be considered
a bit strange, too, but it's not strictly a _bug_.)
chris
------------------------------------------------------------------------------