Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!faustus
From: faustus@ucbcad.UUCP
Newsgroups: comp.lang.c
Subject: Re: Pointer comparison and Portability
Message-ID: <1286@ucbcad.berkeley.edu>
Date: Tue, 24-Feb-87 17:53:03 EST
Article-I.D.: ucbcad.1286
Posted: Tue Feb 24 17:53:03 1987
Date-Received: Fri, 27-Feb-87 03:31:21 EST
References: <4537@brl-adm.ARPA>
Organization: CAD Group, U.C. Berkeley
Lines: 26

In article <4537@brl-adm.ARPA>, Schauble@mit-multics.arpa (Paul Schauble) writes:
> Unfortunately, the Intel 8086 series provides another counter example.
> On this machine, address are in the form of segment and offset.  The
> Actual Address is 16*segment + offset.  This is usually written as
> segment:offset.  Thus, the two pointers 0100:0010 and 0101:0000 point at
> the same byte.  If compared, they will *NOT* compare equal.

I think they will have to compare equal.  If the compiler generates
naive code to compare them it's wrong.  Just as "!p" MUST be true
after a "p = 0", where p is a char * and the machine uses a NULL pointer
that isn't an all-zero bit pattern, "p == q" MUST be true if they
point at the same address, no matter what they look like internally.

> Seems like when K & R says that pointer comparison is undefined except
> when the two are pointers to the same array, it should be taken to mean
> exactly that for all operators, including == and !=.

I think you want to re-phrase this.  If this were literally true then
"p = q; if (p == q) ..." would have undefined semantics.

This is sort of a moot point anyway, since presumably there is no way that
you could get a "de-normalized" pointer within C without using backdoor
casting of values...  But you're just asking for trouble if you ignore the
possibility.

	Wayne