> People are complaining about code breakage with the new sigset_t.
> Correctly written code should *not* have problems.
> But I thought I'd take us all on a quick tour of signal.h to explain
> what's changed, and why it doesn't (shouldn't) matter --- and why some
> programs written by lousy programmers break.
Very true, I wish everybody reads this. Fortunately things evolved a
bit since glibc is available. So patches for all the problems are
already available.
> The most common example I've seen is where a
> programmer tests to see if any signals are blocked with something like:
>
> sigset_t s;
> ...
> if (s) {
> ...
> }
>
> Nice, terse, and idiotic. After all -- where is the sense of the sigset
> bits defined? Who says 'blocked'==1? [I actually have no clue. Maybe
> 'blocked'==0]. However, libc didn't provide any alternative other than:
>
> for (i=0; i<_NSIG; i++)
> if (sigismember(&s, i)) break;
> if (i<_NSIG) {
> ...
> }
glibc provide a non-standard function
/* Return non-empty value is SET is not empty. */
extern int sigisemptyset __P ((__const sigset_t *__set));
and several other goodies for sigset_t.
-- Uli
---------------. drepper at gnu.org ,-. Rubensstrasse 5
Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper at cygnus.com `------------------------