Numerical Recipes is non-portable code

[Rob Carriere]

In article <7142 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) 
writes:
>rob at kaa.eng.ohio-state.edu (Rob Carriere) writes:
>>marv at ism780.UUCP (Marvin Rubenstein) writes:
>>>[In a hypothetical extended C, with arrays x[5:49] and y[0:44], and an
>>>integer variable i, the accesses `x[i]' and `y[i-5]' should generate the
>>>same code on a reasonable compiler.]
>>
>> [ disagree ]
>If the architecture in question is "normal", then the compiler *is* free to do
>that optimization.  If the hardware will fault on the mere mention of an
>illegal pointer, then it can't optimize it -- but how do you think it's going
>to implement z=x[i], then?  They'll still generate the same code, but in this
>case it'll be equally bad rather than equally good.

Actually, if the system has memory to burn, the compiler might
allocate the 5 extra int's (probably only doing so for small lower
bounds, but those do make up almost all the cases anyway).  This is
similar to the fix to the Numerical Recipes vector() routine that I
posted a while ago.

Rob Carriere
"There's nothing quite like a broken architecture"