Subject: Re: Problems with sigismember macro?
To: None <firstname.lastname@example.org>
From: Mark Gooderum <email@example.com>
Date: 09/14/1994 17:52:04
I believe this was done already...I recall a discussion on this.
BTW...if you want to write portable code, this idiom *doesn't* work.
And I don't mean sigismember() problems...
An invalid signal number doesn't mean you're past the valid signal number.
Your best bet is using NSIG or picking some arbirtrary maximum, and if you
really care, keeping a mask of valid signals.
Solaris 2.3 and 2.4 are examples of OS's where this isn't true (there
are others though)...the signals go up to about 33, then skip into a
higher range. There are also signals that are only valid for your
process if you are realtime versus timesharing.
Finally, even the function sigismember() isn't a way to determine if a
signal is valid, it will still typically run and work through to some
maximum (NSIG-1 often), even though there may be holes in this range.
To determine truely valid signal numbers, you have to invoke something
like sigaction() that calls the OS to be sure.
Also, some programs decide to be cute and catch all signals. This
isn't safe either...if you do it on Solaris 2.3/2.4 (again), you'll
never block on a signal because you are handling SIGLWP...which is sent
when all your LWPs are blocked...fun.
These minor bits may not matter to you, but they might, so I'm sharing them
from the experience of porting some serious systems level code to things
as diverse as AIX, Solaris, SunOS, DG/UX, and more...don't even ask me
about restartable system calls on HP/UX...