[cfe-dev] Relational operators on pointers

Steve Vormwald sdvormwa at cray.com
Wed Oct 12 15:13:19 PDT 2011


> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of David Chisnall
> Sent: Wednesday, October 12, 2011 4:55 PM
> To: Stefan Marr
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] Relational operators on pointers
> 
> On 12 Oct 2011, at 09:29, Stefan Marr wrote:
> 
> > As far as I understand from the standard (Sec. 5.9) and various
> discussions on comp.std.c++ the use of >=, < etc. is not generally
> defined for pointers.
> >
> > However, it says, it should be defined for pointers on the same
> array.
> >
> > So, what I would expect to work is a comparison of char* >= char* in
> any circumstances.
> > No matter from where I obtain those pointers.
> 
> Assuming that the C++ specification says the same thing as the C
> specification, comparisons between pointers in different object
> (allocations) is undefined.  This is independent of what you cast the
> pointers to.  I believe this part of the specification was intended to
> allow for segmented memory architectures, where pointers do not
> necessarily have a meaningful ordering outside of an allocation and can
> be moved around (e.g. Burroughs Large Systems architecture).
> 
> If you want to compare two unrelated pointer types, then you should
> first cast them to an integer type.  Pointer to integer casts (that do
> not involve truncation) are required to give a unique integer
> representation of the pointer.  So, if you want to do a comparison
> between two unrelated pointers as unsigned values, the safest thing to
> do is cast them to uintptr_t and then do the comparison.
> 

What if I have an object that happens to include addresses both with and without the sign bit set?  Does pointer comparison still work correctly?  If I read Stefan's mail correctly, that is a possibility since the heap spans that boundary and thus objects allocated within it could as well...
	
Steven Vormwald





More information about the cfe-dev mailing list