Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP
Path: utzoo!decvax!ucbvax!ucdavis!lll-crg!mordor!ut-sally!jsq
From: jsq@ut-sally.UUCP (John Quarterman)
Newsgroups: mod.std.unix
Subject: problem with signal() in D5
Message-ID: <2961@ut-sally.UUCP>
Date: Sat, 21-Sep-85 18:26:41 EDT
Article-I.D.: ut-sally.2961
Posted: Sat Sep 21 18:26:41 1985
Date-Received: Sun, 22-Sep-85 12:18:44 EDT
Reply-To: std-unix@ut-sally.UUCP
Organization: U. Texas CS Dept., Austin, Texas
Lines: 54
Approved: jsq@ut-sally.UUCP

Date:     Fri, 20 Sep 85 11:53:29 EDT
From: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
To: std-unix@ut-sally.ARPA

I checked with X3J11 and the proposed change in the declaration of
user signal-handling functions has a problem.

The proposed change in the declared type of a signal handler was to:
	void func( int sig, ... );
where the ", ..." was intended to allow provision of additional
information (such as PC at time of fault) to the signal handler,
in a "signal and implementation dependent" way.

This is a nice idea, but according to X3J11 in order to guarantee
portability one would have to define all signal handlers with the
same ", ..." notation.  The fundamental reason behind this
requirement is that some C implementations will use a different
function parameter passing mechanism for variable parameter lists
than for regular lists.

This means that existing code such as
	void
	onintr( sig )			/* SIGINT catcher */
		int	sig;
		{
		do_something_with( sig );
		}
would officially be broken.  (Of course, many UNIX C implementations
on "nice" architectures would continue to work anyway.)

In order to avoid having to recode signal handlers to look like
	void
	onintr( int sig, ... )		/* SIGINT catcher */
		{
		do_something_with( sig );
		}
I recommend that the "optional" extra signal handler function
parameter(s) be removed from the proposed specification.  I agree
that a better signal interface would be desirable, and suggest
that the "real time extensions" subcommittee should consider this
issue (hopefully, they will use a different mechanism such as
4.2BSD's if they need to change the semantics).

Incidentally, the reason that this variable parameter list issue
is not a problem with open(), execl(), printf(), etc. is that the
application developer ("user") sees those functions from the
outside only, not from the inside (i.e., he uses their declarations
but does not have to provide a definition).  For brand-new
facilities there is also no problem, since X3J11 provides a
"stdargs" mechanism to provide a portable way to implement such
function definitions.  It is only when compatibility with past
function definitions is involved that a problem can arise.

Volume-Number: Volume 2, Number 5


Brought to you by Super Global Mega Corp .com