From -5124504488414800630
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-10-16 16:02:42 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!microsoft!hexnut!jimad
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Oct16.234851.28948@microsoft.com>
Date: 16 Oct 92 23:48:51 GMT
Organization: Microsoft Corporation
References: <9225302.22791@mulga.cs.mu.OZ.AU> <4945@holden.lulea.trab.se> <1992Sep10.094957.23588@jyu.fi>
Lines: 24

In article <1992Sep10.094957.23588@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
|My opinion:  the idiom is sensible, in many cases even necessary.
|It is the pertinent part in the language definition that is broken,
|obviously (as explained by Johan above) in order to facilitate
|efficient implementation on obsolescent machine architectures.
|Was it William Wulf who wrote approximately: "More sins in programming
|are committed in the name of efficiency than all other reasons combined,
|including sheer stupidity"?

Note that many of the newest RISC machines also feature segmented architectures,
and are typically run with their compilers in a mode where pointer comparsions
are not done on the segment part.  

But in any case, at least my PC compiler (Large Model)
performs == and != comparisons based both on the segment and offset parts.
Its the ordered comparisons > < >= <= where only the offset part is compared.
Thus == != work for all ptrs.  > < >= <= only work within an array.

Which is as it should be.

I think the standard should define == != to always work on ptrs of comparable
types -- assuming those ptr are pointing at legitimate objects or one past
the end of a legitimate array.  > < >= <= to be only defined within an array
or one past its end.