Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekfdi!videovax!bart
From: bart@videovax.tv.tek.com (Bart Massey)
Newsgroups: comp.lang.c++
Subject: Re: Re: references to dereferenced null pointers, etc...
Message-ID: <5767@videovax.tv.tek.com>
Date: 23 Mar 90 00:14:14 GMT
References: <PCG.90Mar14085521@rupert.cs.aber.ac.uk> <1520025@hpmwjaa.HP.COM>
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 25
In-Reply-To: <5763@videovax.tv.tek.com>

In private mail to me, someone writes:
 > In article <5763@videovax.tv.tek.com> you write:
 > >In article <1520025@hpmwjaa.HP.COM> jeffa@hpmwtd.HP.COM (Jeff Aguilera) writes:
 > >>The only portable solution that I can think of is O(N) time complexity:
 > >>         for (register int k=0; k<N; ++k) if (p+k==q) return 1;
 >
 > >I don't think so.  Even your O(N) solution is non-portable: if p and q are
 > >in different "segments" on a segmented machine, they are allowed to compare
 > >*equal* even if they point to different objects, since the result of the
 > >comparison is undefined [ANSI C Draft 12-7-88 3.3.8,3.3.9]!
 >
 > Read section 3.3.9 again.  The *relational* operators require the operands to
 > be in the same array, but the *equality* operators do not.  On a segmented
 > machine, the algorithm must work, even it has to do extra work to normalize
 > the pointers and generate a 32-bit compare.
 > 
 > "If two pointers ... compare equal, they ... both point to the same object."

You know, he's right -- I blatantly misread the ANSI draft.  My apologies to
Jeff, and to the rest of the net.  While I in no way endorse the
above-referenced solution (:-), it is correct...

					Bart Massey
					..tektronix!videovax.tv.tek.com!bart
					..tektronix!reed.bitnet!bart