Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!bu-cs!husc6!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Pointer arithmetic and comparisons.
Message-ID: <15429@haddock.ima.isc.com>
Date: 13 Dec 89 21:41:35 GMT
References: <257ECDFD.CDD@marob.masa.com> <232@bohra.cpg.oz> <2908@murtoa.cs.mu.oz.au>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 22

In article <2908@murtoa.cs.mu.oz.au> rob@murtoa.UUCP (Robert Wallen) writes:
>Although K&R sez that you should be able to do p < q where p and q point to
>members of the same array, Turbo C hangs an extra requirement on you.  That
>is, that the pointers are normallized as well.

If the pointers point into the same array, which is smaller than 64K, why
shouldn't they already be normalized?

>Now a beef.  Why check for (p <= pend)?  Why not just (p == pend) ?

I believe this one is in The Elements of Programming Style.  To roughly
paraphrase from memory (it's been a decade since I read it): when either of
two comparisons is correct (because the case where they differ "can't
happen"), it's considered better to use the one that would stop the loop in
the event that the "impossible" happens.

Also, in a segmented implementation (p == q) is generally slower.  For
equality compares, the compiler has to ensure that the pointers are
normalized, but with non-huge use of (p < q) it can assume that the pointers
will already be in the same segment.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint