RC on HP9000/710?

RC on HP9000/710?

[rsalz]

Anyone got rc running on a Snake, HP9000/710?  rc.trip fails, and I haven't
started looking yet.  Built with gcc, so it may be suspect.  Tnx.

	/r$

Re: RC on HP9000/710?

[Scott Merrilees]

>Anyone got rc running on a Snake, HP9000/710?  rc.trip fails, and I haven't
>started looking yet.  Built with gcc, so it may be suspect.  Tnx.

I built it on a 9000/817, then just used the binary on the 9000/715s
we eventually got.  I didn't try rc.trip.  I've been using it for
months.

Sm

Re: RC on HP9000/710?

[Tom Culliton x2278]

Rich says:
> Tnx for the note.  I think run-time lookup isn't going to cost a lot...

It would be more robust at a minor run time cost, but that just masks
the problem.  At the base of it is the fact that the mksignal script
gets confused if sys/signal.h is not relatively simple.  We need a way
to detect this at compile time.

Tom

Re: RC on HP9000/710?

[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

Re: RC on HP9000/710?

[rsalz]

I got rc built and passing the trip test yesterday.  I had to build
sigmsgs by hand.  This was on an HP9000/710, running HP-UX 9.01.  The
<sys/signal.h> header file just cannot be parsed by mksignal.  I think
because it gets confused by multiple NSIG and _NSIG #define's.

The more I think about it, the more I don't like the way rc uses signals
as indicies.  I would rather see it extend sigmsgs to contain rows like
	{SIGTERM, "sigterm", "terminated"}
Then, rather then using a signal as an index, it looped through the table
to find the matching SIGxxx, and then used the table subscript as the
index.  It might be possible to generate this table automatically.

A quick look seems to show that es works the same way.  While I wouldn't
call it a show-stopper, I think it, too, should be fixed.
	/r$