Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: volatile
Message-ID: <7669@brl-smoke.ARPA>
Date: 12 Apr 88 14:26:37 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <7594@brl-smoke.ARPA> <1045@mcgill-vision.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <1045@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>In article <7594@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>> In article <1264@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
>>> static void catch(int signo, code; struct sigcontext *scp) { gotcha = 1; }
>> This Berkeley extension does not conform to the standard,
>Berkeley practice seems pretty firmly established to me.

Far from it; the additional arguments were a fairly recent change in
the Berkeley variant of UNIX; they run counter to the established
definition and implementation of signal() AT THE TIME BERKELEY DECIDED
TO CHANGE THEIR IMPLEMENTATION, and to top it off, the problem of
variadic argument lists wasn't dealt with (because all the world's
a VAX, presumably).  Thus Berkeley's approach is simply not suitable
for an OS-independent standard.  I wish they would invent new
interfaces when they decide to change things like this.