Path: utzoo!attcan!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: shared memory under SysV
Message-ID: <7906@brl-smoke.ARPA>
Date: 17 May 88 07:35:59 GMT
References: <14379@brl-adm.ARPA> <10861@steinmetz.ge.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <10861@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  I think this is a major conflict with ANSI C. The procedure must
>return either an int or a pointer, but it can't portably do both, since
>some systems don't represent the two types remotely the same way. This
>works on the nice machine on which SysV was developed, but you better
>hope that what's really returned for an error is "(char *) -1".

This botch has nothing to do with ANSI C.  A lot of old UNIX code
(mostly inherited from PDP-11-only days) did not properly distinguish
between integers and pointers.  Due to the way the system call error
handling routine worked, functions such as sbrk() returned some form of
-1, perhaps ((char *)-1), on error.  Obviously the proper C design for
such error returns (reported in-band in a nominally pointer value)
would be a null pointer, not some sort of cast -1.

Why this wasn't fixed when the IPC stuff was added for USG 4.x I don't
know.  Probably the same reason the PWB/Graphics unportable uses of
getc() were "fixed" by adding #if u3b2 instead of doing it right.