Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: "Numerical Recipes in C" is nonportable code
Message-ID: <1673@dataio.Data-IO.COM>
Date: 29 Aug 88 18:11:50 GMT
References: <664@lindy.Stanford.EDU> <6758@megaron.arizona.edu> <718@gtx.com> <13258@mimsy.UUCP> <531@accelerator.eng.ohio-state.edu>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 27

In article <531@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu (Rob Carriere) writes:
<In article <13258@mimsy.UUCP< chris@mimsy.UUCP (Chris Torek) writes:
<< [ still on the b = malloc( foo );  bb = b - 1; code in NumRecipes ]
<<Such an implementation will ABORT ON THE COMPUTATION `b - 1',
<<possibly (indeed, preferably) at compile time.  And it is legal!
<So the standard says, they tell me.  It is also one the more flagrant
<violations of the Principle of Least Astonishment I've seen in a
<while.

On a segmented architecture, like 8086's, malloc can and does return
a value that is a pointer to the beginning of a segment. That is, there
is a 16 bit selector and a 16 bit offset, the offset portion is 0 or a
very small number. Thus, subtracting a value from the pointer could result
in a segment wrap. Trouble occurs when you do things like:
	array = malloc(MAX * sizeof(array[0]));
	for (p = &array[MAX-1]; p >= &array[0]; p--)
		...
The >= will fail, because the last p-- will cause an underflow and now
p is greater than &array[MAX]! I've encountered this many times in
porting code from Unix to PCs. The correct way to write the loop is:
	for (p = &array[MAX]; p-- > &array[0]; )
or something similar.

Please, no flames about Intel's architecture. I've heard them all for years.

The best way to learn to write portable code is to be required to port
your applications to Vaxes, 68000s, and PCs. (I have all 3 on my desk!)