(char *)-1

[Karl Heuer]

In article <10300008 at exunido.UUCP> jl at 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 at haddock.isc.com), The Walking Lint