Path: utzoo!attcan!uunet!lll-winken!ames!ucsd!chem.ucsd.edu!tps
From: tps@chem.ucsd.edu (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Re: signal & sigvec error return codes
Keywords: signal sigvec error
Message-ID: <488@chem.ucsd.EDU>
Date: 28 May 89 04:56:57 GMT
References: <8044@batcomputer.tn.cornell.edu>
Reply-To: tps@chem.ucsd.edu (Tom Stockfisch)
Distribution: comp
Organization: Chemistry Dept, UC San Diego
Lines: 30

In article <8044@batcomputer.tn.cornell.edu> lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) writes:
_     Do all vendors still document the return code of signal and
_sigvec as being -1 (implicitely an int)?  My problem with this is
_that if you try to be a "good" programmer and check for an error as
_in 
_    if(signal(SIGINT, SIG_IGN) == -1){
_      perror("signal");
_      exit(1);
_    }
_say, you will either get a warning or an error, depending on how smart
_your compiler is.  Why not document the error return as being something
_along the lines of SIG_ERR, where SIG_ERR is defined as
_#define SIG_ERR ((int(*)())-1)
_in <signal.h>?

This last cast gets warnings from many compilers (e.g. gcc).

Why isn't this implemented without the potentially unportable
and kludgey cast of -1?

signal.h:
	int	SIG_ERR(), SIG_IGN(), SIG_DFL();

signal.c:
	int	SIG_ERR(){assert(0);}
	int	SIG_IGN(){assert(0);}
	int	SIG_DFL(){assert(0);}
-- 

|| Tom Stockfisch, UCSD Chemistry	tps@chem.ucsd.edu