Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!rob
From: rob@cs.mu.oz.au (Robert Wallen)
Newsgroups: comp.lang.c
Subject: Re: Pointer arithmetic and comparisons.
Message-ID: <2908@murtoa.cs.mu.oz.au>
Date: 11 Dec 89 22:57:40 GMT
References: <257ECDFD.CDD@marob.masa.com> <232@bohra.cpg.oz>
Reply-To: rob@murtoa.UUCP (Robert Wallen)
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 28

In article <232@bohra.cpg.oz| ejp@bohra.UUCP (Esmond Pitt) writes:
|In article <257ECDFD.CDD@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes:
|>
|>One method I use to avoid overflow while filling a buffer is to set a
|>pointer to the address of the last element (&buffer[last]), then compare
|>the current buffer position to the end pointer, testing that "current"
|>is never greater than "end" ...

You dont work on GNU by any chance, do you?  They seem to have this annoying
habit.  Annoying because its hard to port to most DOS compilers where memory
is broken up into stupid little chunks with segment/offset pairs

|>This method has never bitten me on Unix/Xenix/*nix systems of any
|>flavor, on machines ranging from 286's to 68K's to Sparcs.  Now, in an
|>attempt to port to MSDOS/Turbo-C, this method breaks.

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.  Either use the HUGE model or
normalize the pointers before comparison.  This has made my porting of gnu-egrep
real tedious to the point of not bothering...

Personally, I favor wasting a whole integer and keeping track of the number
of elements that I have used already; integer comparison is not only 
guaranteed to work, it should be fasted given sizeof(int)<sizeof(int *)

Now a beef.  Why check for (p <= pend)?  Why not just ( p == pend) ?  After all,
its not as though your code might accidentally skip over the last entry !!