Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!decwrl!decvax!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: signal & sigvec error return codes
Keywords: signal sigvec error
Message-ID: <13395@haddock.ima.isc.com>
Date: 25 May 89 23:11:31 GMT
References: <8044@batcomputer.tn.cornell.edu> <10319@smoke.BRL.MIL>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Distribution: comp
Organization: Interactive Systems, Boston
Lines: 19

In article <10319@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <8044@batcomputer.tn.cornell.edu> lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) writes:
>>Why not document the error return as being something [like]
>>#define SIG_ERR ((int(*)())-1)
>
>That's exactly what pANSI X3.159 requires (the macro, not the particular
>value), except you have the type wrong -- it should be ((void(*)())-1).

Actually, it's ((void (*)(int))-1), but the above is the next best
approximation if you don't have prototypes.

Interestingly, though, certain implementations that provide the "software
signal" package (gsignal/ssignal) now have a problem, because this package
really does use int-valued handlers.  (The return value is examined by the
implementation, to decide whether the condition has been properly handled.)
Unfortunately, they also attempt to use the same header file and macro names,
so there's a type clash.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint