Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!umd5!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: sbrk return (was: att & osf)
Message-ID: <8369@smoke.ARPA>
Date: 22 Aug 88 18:28:54 GMT
References: <4964@killer.DALLAS.TX.US> <3395@vpk4.UUCP> <1988Aug5.211217.21037@utzoo.uucp> <2998@homxc.UUCP> <1988Aug19.204836.23395@utzoo.uucp> <3498@encore.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <3498@encore.UUCP> bzs@encore.UUCP (Barry Shein) writes:
>Consider that sbrk() returns -1 (specifically, (char *)-1) as an error
>code in all Unix's I know of (BSD, SYSV.)

Actually it's not clear WHAT sbrk() returns for an error indication,
when expressed in C.  Traditionally (because of usage of a common
error handling return by all system call interfaces) it returns an
int with value -1, which may not even be in the same register as a
char * is returned in.  This is a horrible botch that COULD have been
fixed over the years by a phased transition strategy:
	0) existing bogus -1 return from sbrk
	1) edit applications to accept bogus -1 or useful 0 for error
	2) change sbrk to return 0 on error
	3) (optional) edit applications to no longer check bogus -1.
Other similar problems have been fixed by such a strategy.

The analogous IPC botch is less excusable, as the final form of that
interface was frozen several years after the problem with -1 as a
char * was well known.

P.S.  To avoid the problem with sbrk(), change
	if ( sbrk( incr ) == ??? )
		error();
to
	curbrk = sbrk( 0 );
	if ( brk( curbrk + incr ) == 0 )
		error();