"Numerical Recipes in C" is nonportable code

[Henry Spencer]

In article <531 at accelerator.eng.ohio-state.edu> rob at kaa.eng.ohio-state.edu (Rob Carriere) writes:
>>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.  In fact, while we're at it, it would seem to violate the idea
>that you give the programmer all the rope she asks for, because she
>just might be needing it to pull herself out of a bog.  Gentlemen
>system programmers, surely you too have algorithms that are more
>accurately expressed with arrays from other than base zero?

Yes, certainly.  However, if one wants such code to be portable, one must
be careful how one computes addresses into such arrays.  The only fully
portable way to compute a[b] when you want "a" to start at subscript "s"
is a[b-s].  (a-s)[b] certainly is appealing, since it permits doing the 
subtraction once rather than every time, but it is *NOT PORTABLE*.  Thanks
primarily (but not exclusively) to Intel, it is not safe to back a pointer
up past the beginning of an array and then advance it again.  C has never
guaranteed this to work; indeed, there have always been explicit warnings
that once the pointer goes outside the array, all bets are off.  X3J11 has
legitimized pointers just past the end of an array, since this is very
common and is cheap to do, even on difficult machines, but the beginning
of an array remains an absolute barrier to portable pointers.  This is
simply a fact of life in the portability game.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry at zoo.toronto.edu