Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: signal functions
Message-ID: <11063@mimsy.UUCP>
Date: 14 Apr 88 18:01:58 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <1988Apr13.164012.513@utzoo.uucp>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

[signal functions are called with three arguments in 4.[23]BSD:
    f(int signum, int code, struct sigcontext *scp)
]
>>Berkeley practice seems pretty firmly established to me.  What sort of
>>OS-centricism is going on here?

In article <1988Apr13.164012.513@utzoo.uucp> [love those message IDs]
henry@utzoo.uucp (Henry Spencer) writes:
>Berklocentrism, and it's you that's doing it.  Recent releases of x.yBSD
>are the *only* variants of Unix that interface to signal handlers in that
>way. ... on any machine that has trouble with varargs functions; the
>Berkloids have this wretchedly stupid habit of not giving new interfaces
>new names.  All the world's a VAX, right?  Grr.

Well, they do have that habit (`I argues and I argues and all I gets
is a tired jaw'), but in this case you are wrong.  Well, you are right
*and* wrong.  The true signal interface in 4.2/4.3BSD is the `sigvec'
system call; the `signal' interface is emulated in the C library.
That emulation could (but does not now, on the Vax and Tahoe, where
it happens to be unnecessary) arrange to call `signal' handlers
with only one argument, while `sigvec' handlers would get all three.

Moreover, while the second argument and third arguments are overly
Vaxish, something along the lines of the third, at least, is necessary
for doing decent signal handing in the first place.

They did give the new interface a new name, and the new interface is
useful.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris