Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <462@haddock.UUCP>
Date: Tue, 28-Apr-87 12:47:20 EDT
Article-I.D.: haddock.462
Posted: Tue Apr 28 12:47:20 1987
Date-Received: Wed, 29-Apr-87 05:49:14 EDT
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <2440@ulysses.homer.nj.att.com> <148@sds.UUCP>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 27
Summary: error return from signal and other syscalls

In article <148@sds.UUCP> dave@sds.UUCP (dave schmidt x194) writes:
>But what about K&R saying "A pointer to which 0 has been assigned is
>guaranteed not to point to any object..."?  I think an exception exists
>to this within the standard UNIX C library. Signal() returns a pointer
>to a function; in the event of an error, -1 is returned, not 0.

This is no longer true (and should never have been true).  The error return
from ANSI signal is the constant SIG_ERR, and its value is, of course, not
specified.  (Although it happens to be ((void (*)(int))-1) on current UNIX
implementations, there is no guarantee that this cast is meaningful in
general.)

>As far as I know, all other functions that return a pointer, return 0 on
>error.

System calls do not, for absurd historical reasons.  (The other exceptions are
sbrk and shmat.)  Hopefully this will change soon.

>On the other hand, if 0 cannot be a valid function address, why does
>signal not return 0 on error?  I would be curious to know.

The function signal() has three out-of-band return values: SIG_ERR, SIG_DFL,
and SIG_IGN.  At most one of them can have the value ((void (*)(int))0).  (In
current implementations, it happens to be SIG_DFL; but this fact should be
completely transparent to the programmer.)

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