Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!uhura.cc.rochester.edu!sunybcs!bingvaxu!leah!itsgw!steinmetz!uunet!ateng!chip
From: chip@ateng.ateng.com (Chip Salzenberg)
Newsgroups: comp.std.c
Subject: Re: pointer comparisons in dpANS C
Message-ID: <1988Oct21.143640.10468@ateng.ateng.com>
Date: 21 Oct 88 18:36:39 GMT
References: <1988Oct11.143728.28627@gpu.utcs.toronto.edu> <6777@chinet.chi.il.us> <8696@smoke.ARPA> <14061@mimsy.UUCP>
Organization: A T Engineering, Tampa, FL
Lines: 27

According to chris@mimsy.UUCP (Chris Torek):
[sample program deleted]
>Every address returned by malloc must compare as not distinct from
>every other address, lest this routine delete the wrong object.

Quite.

As a data point:  C compilers for the '286, when generating "far" pointers
(16 bits segment, 16 bits offset), generally ignore the segment portion of
pointers when testing their relative magnitudes ("<", ">=", etc).  However,
tests for equality and inequality ("==", "!=") always compare all 32 bits.

I understand why this choice might be made, and it certainly passes Henry's
test program.  Nevertheless, it can be surprising -- perhaps incorrect? --
that:

	((p >= q) && (p <= q))

is not the same as:

	(p == q)

Ah well, yet another '286 "feature".
-- 
Chip Salzenberg             <chip@ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	   Beware of programmers carrying screwdrivers.