Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Universal OS (was Re: Survey of architectures)
Message-ID: <51046@sun.uucp>
Date: 27 Apr 88 16:51:31 GMT
References: <50825@sun.uucp> <670016@hpclscu.HP.COM>
Sender: news@sun.uucp
Lines: 77

> I presume that by broken UNIX systems, you mean "most" UNIX system.

You presume incorrectly.  I know of no UNIX systems that *require* you to write
signal handlers as:

	handler(signo, code)
		int signo;
		int code;
	{
		...
	}

If you omit the "code" argument, they will still work.

> What am I going to do with that ubiquitous "SIGFPE"?

Either:

	1) do what 4BSD does, and rely on the fact that, in *most* current C
	   implementations, you can get away with the above;

	2) come up with a scheme where you can specify whether extra arguments
	   are to be delivered to a signal handler;

or

	3) use only the 4BSD signal mechanism, or the 4BSD-derived POSIX signal
	   mechanism, and in the "sigaction" structure declare the "sa_handler"
	   field as a pointer to a function with a variable-length argument
	   list:

		void	(*sa_handler)(int, ...)

1) will cause problems with ANSI C; "signal" takes an argument that is a
pointer to a function with one and only one argument, and the compiler will
give you a warning if you try to cast the address of a function with more
arguments to the type "pointer to a function with one argument".

3) is kind of rude.

2) is easy:

	struct sigaction {	/* speaking here in POSIX terms */
		union {
			void	(*sau_old_handler)(int signo);
			void	(*sau_new_handler)(int signo, int code);
		} sa_handler_union;
		sigset_t	sa_mask;
		int		sa_flags;
	};

	#define	SA_CLDSTOP	0xnnnn
	#define	SA_NEWHANDLER	0xmmmm
	...

	#define	sa_handler	sa_handler_union.sau_old_handler
	#define	sa_newhandler	sa_handler_union.sau_new_handler

If SA_NEWHANDLER is set, the "sau_new_handler" member is used; otherwise, the
"sau_old_handler" is used.  Non-stupid programs written to the POSIX interface
will set the flags field to a value that doesn't have the SA_NEWHANDLER bit
set, so they will work OK.  Programs that want to have handlers that receive
the signal code will have to set that bit, but that's life.

> > Thus, the issue of the interface to the signal handler is not an issue
> > raised by multiple versions of UNIX.  It *is* an issue if you have
> > non-UNIX systems, but if you have to deal with non-UNIX systems, it's
> > probably one of the least of the issues you will have to deal with.
> 
> This is not particularly a UNIX problem, it's an architecture problem.

Bullshit.  If you don't have the UNIX/POSIX signal mechanism, or the ANSI C
signal mechanism, you can easily define a signal mechanism that solves this
problem.  The *only* problem is that the ANSI C signal mechanism (which will
presumably, once ANSI C is adopted, spread its influence to the POSIX signal
mechanism) demands that signal handlers take only one argument.  Thus, this is
*at most* an ANSI C problem.