Re: RC on HP9000/710?

[culliton@srg.af.mil (Tom Culliton x2278)]

I encountered exactly the same thing with SCO Unix for about the same
reason.  The smaller NSIG was being used top size the array and then
signals that were off the end of the array where stomping memory.  At
the time Byron said that others folks had the same problem with HP/UX. 
Here's the message:

> From srg.srg.af.mil!archone.tamu.edu!byron Fri May 22 04:30:33 1992
> From: Byron Rakitzis <byron@archone.tamu.edu>
> To: culliton@srg.srg.af.mil
> Subject: sigmsgs.c
> Date: Fri, 22 May 1992 02:33:32 -0500
> Status: RO
> 
> Here's the problem: SCO has different NSIG's and mksignal simply
> goes for the last NSIG it sees in /usr/include/sys/signal.h.
> 
> I don't know an easy answer to this conundrum, except to advise
> SCO users to build this thing by hand; there is already another
> OS out there with a braindead signal.h: HP/UX, and I think people
> there get the idea also.
> 
> I dunno, any ideas?
> 
> BTW, I assume that rc with a healthy sigmsgs.c runs ok, right?

I don't think that using the signal numbers as indices is a problem but
at the time, I did suggest a range check be done.  The right way to do
this is probably at compile time using #if and #error so that you get
an error when you try to build the code and don't add any run time
overhead.  For example in walk.c there is a #if that looks like this: 
(this is the one that screwed up SCO)

#if !defined(NOJOB) && defined(SIGTTOU) && defined(SIGTTIN) && defined(SIGTSTP)

If we added:

#if (SIGTTOU >= NUMOFSIGNALS) || (SIGTTIN >= NUMOFSIGNALS) || (SIGTSTP >= NUMOFSIGNALS)
#error mksignal failed, you may have to build sigmsg.c by hand
#endif

This wouldn't be so hard to track down.  The other thing that would
help is a note in config.h or the README to the effect that SCO-ODT and
HP/UX have this problem.

Tom