Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!pyrnj!mirror!ima!haddock!karl
From: karl@haddock.UUCP (Karl Heuer)
Newsgroups: comp.lang.c
Subject: (char *)-1
Message-ID: <185@haddock.UUCP>
Date: Thu, 4-Dec-86 20:26:57 EST
Article-I.D.: haddock.185
Posted: Thu Dec  4 20:26:57 1986
Date-Received: Fri, 5-Dec-86 06:06:30 EST
References: <5009@brl-smok.UUCP> <10300008@exunido.UUCP>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 29

In article <10300008@exunido.UUCP> jl@exunido.UUCP writes:
>[someone writes:]
>>However, in SysV the shmat(2) call returns (char *) -1 in case of error.
>>Is anyone aware of any computer where this would not work as intended?
>
>[On some architectures with 24- or 31-bit pointers,] -1 interpreted as a
>pointer is either 0x00FFFFFF or 0x7FFFFFFF.  What shall the compiler
>generate for (char *)-1 ???

As long as it's consistent, it doesn't matter.  The only thing you can do
with a bastard value like (char *)-1 is compare it with another object that
was generated the same way.  This "should" be safe, although that pattern
might also be a valid address.

As someone mentioned, NULL would've been a better choice for the error return
on system calls that return pointers.  Someone slipped up back on the pdp11
with sbrk().  (Ah, hindsight.)  I don't think there was any need to use the
same cerror label; after all, lseek() was already a special case.

>We have the same problem with the signal function ...

Oh yeah, signal() actually has three non-pointer returns -- I suppose they
could've used NULL for error here as well, and invented some other out-of-band
value for SIG_DFL.  (I'm glad they've stopped documenting such non-portable
statements as "any odd value means SIG_IGN"!)  Well anyway, as you mentioned
(and I edited out), ANSI seems to be nudging this in the right direction with
SIG_ERR; maybe there's still hope.

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