Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!apollo!mrst!sdti!turner
From: turner@sdti.SDTI.COM (Prescott K. Turner)
Newsgroups: comp.std.c
Subject: Testing Equal Pointers (was: detecting invalid pointers)
Message-ID: <375@sdti.SDTI.COM>
Date: 23 Mar 89 17:08:00 GMT
References: <1989Mar21.085704.15894@ateng.ateng.com> <16039@cup.portal.com>
Reply-To: turner@sdti.SDTI.COM (Prescott K. Turner, Jr.)
Organization: Software Development Technologies, Sudbury MA
Lines: 34

The quotes below are from comp.lang.c.

In article <1989Mar21.085704.15894@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes:
> For totally correct comparisons of all pointers, it's necessary
> to normalize them by hand, or be sure that they are cast to "huge *" when
> any pointer arithmetic is done.  Otherwise, the different combinations of
> segment+offset that actually refer to the same address do not compare equal.

In article <16039@cup.portal.com> Kevin_P_McCarty@cup.portal.com writes:
> It is possible however to have two pointers point to the same storage
> location but which compare unequal.  A one-to-one mapping between
> pointers and storage locations is not required.

Why is this dismal situation reflected in the pANS?  How can standard C
let pointers to the same object compare unequal?  Even in Microsoft C
large model there are ways to be sure that your pointer comparisons for
equality/inequality will yield the appropriate result.  

But STANDARD C PROVIDES NO WAY at all to tell if two pointers point to the
same object!  In fact, a compiler could implement (p1==p2) as
(p1==0 && p2==0) and still pass all tests for standard conformance.

Any program is not strictly conforming if it tests for equality of
pointers, gets a 0 result, and then proceeds on the basis that those
pointers do not point to the same object.

It is reasonable that X3J11 made allowances for hardware in exceptional
situations, as when the result of + overflows.  But that is different,
because a strictly conforming program has means to avoid arithmetic overflow.
--
Prescott K. Turner, Jr.
Software Development Technologies, Inc.
375 Dutton Rd., Sudbury, MA 01776 USA        (508) 443-5779
UUCP: ...{harvard,mit-eddie}!sdti!turner    Internet: turner@sdti.sdti.com