While getting CVS compiled on x86 1.0 beta yesterday I ran in
	to a hang when I tried to run it. After mucking around in gdb
	for a bit I found a piece of code in the cvs support library
	that was initializing the signal set. First the defines from
	/usr/include/signal.h:

/* List definitions after function declarations, or Reiser cpp gets upset. */
#define sigaddset(set, signo)   (*(set) |= 1 << ((signo) - 1), 0)
#define sigdelset(set, signo)   (*(set) &= ~(1 << ((signo) - 1)), 0)
#define sigemptyset(set)        (*(set) = 0, 0)
#define sigfillset(set)         (*(set) = ~(sigset_t)0, 0)
#define sigismember(set, signo) ((*(set) & (1 << ((signo) - 1))) != 0)

	I'm not sure if it's a x86 gcc bug or not but the whole signal
	setup macro set looks kinda shakey to me.
	
	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...
	
	I fixed cvs up by just setting the key variable to SIGMAX but the
	assumptions in the above macros make me nervious something like this is
	going to jump up and bite me later in a situation that won't be so
	trivial to fix... B^(.

	Other OS's appear to implement these as actual functions rather than
	macros, maybe NetBSD should too? Or at least make the macros more
	robust. i.e. sigfillset is assuming there are 31 signals and will
	never be any more. sigismember assumes 1<<33 on a 32 bit int would
	do the right(?) thing and return 0; it don't on x86 1.0beta...

	Anyways, it looks like a weak point that should be addressed in the
	future and at least warned about in the present.

		-Rob

------------------------------------------------------------------------------