Comparing pointers to different objects 
Author Message
 Comparing pointers to different objects

A recent thread on a similar topic lead me to this naive question:

We know that == and != are the only relational operators that are
defined when comparing pointers to two different objects.

But what if the system has two or more separate memory spaces and
each object is in its own memory space? Does such a system cease
to be conforming? Or is the implemntation required to provide some
magic trick to make such a comparison defined?

--
Peter Pichler (Increment my "From:" address if your email bounces.)
This message is not solicitation for contact via email or phone.



Sat, 10 Jan 2004 04:49:49 GMT  
 Comparing pointers to different objects

Quote:

> A recent thread on a similar topic lead me to this naive question:

> We know that == and != are the only relational operators that are
> defined when comparing pointers to two different objects.

> But what if the system has two or more separate memory spaces and
> each object is in its own memory space? Does such a system cease
> to be conforming? Or is the implemntation required to provide some
> magic trick to make such a comparison defined?

The standard defines the comparisons of the address of different
objects.  Any conforming implementation must follow this.  If it
doesn't, then it's not conforming.  The implementation doesn't
get a "this is hard to do, so you don't have to do it" free
conformance card.


Sat, 10 Jan 2004 05:19:13 GMT  
 Comparing pointers to different objects

Quote:

>A recent thread on a similar topic lead me to this naive question:

>We know that == and != are the only relational operators that are
>defined when comparing pointers to two different objects.

>But what if the system has two or more separate memory spaces and
>each object is in its own memory space? Does such a system cease
>to be conforming? Or is the implemntation required to provide some
>magic trick to make such a comparison defined?

If each object is in its own memory space, then the pointer needs to
store information about which memory space the object it points to is
in (since that's needed to get at the object), so an implementation can
compare pointers for equality by checking the memory space and then, if
they're equal, the offset into that memory space (so the code generated
for `p==q' would look something like
`p.segment==q.segment && p.offset==q.offset').

Note that an implementation like this makes it easy to see why
inequality comparisions on pointers to different objects are allowed to
break - if two pointers point at objects in different memory spaces,
it's impossible to meaningfully tell which pointer is `greater'.

dave

--

Absolutely. My only point was that, if you're gonna clear the screen anyway, at
least you could have the decency to put it back like you found it. Oh yeah, and
do it in some other newsgroup too.  :-)     --Richard Heathfield in comp.lang.c



Sat, 10 Jan 2004 05:27:15 GMT  
 Comparing pointers to different objects

Quote:

> A recent thread on a similar topic lead me to this naive question:

> We know that == and != are the only relational operators that are
> defined when comparing pointers to two different objects.

> But what if the system has two or more separate memory spaces and
> each object is in its own memory space? Does such a system cease
> to be conforming? Or is the implemntation required to provide some
> magic trick to make such a comparison defined?

    Pointers to different objects must compare unequal, per section
6.5.9, paragraphs 3 and 6:

        "[...] For any pair of operands, exactly one of the relations
        [`==' or `!='] is true."

        "Two pointers compare equal if and only if both are null
        pointers, both are pointers to the same object (including a
        pointer to an object and a subobject at its beginning) or
        function, both are pointers to one past the last element of
        the same array object, or one is a pointer to one past the
        end of one array object and the other is a pointer to the
        start of a different array object that happens to immediately
        follow the first array object in the address space."

(The final clause may be confusing, but I think it's just giving the
implementation permission to do something convenient when the program
indulges in dubious practices.)

    The "if and only if" in paragraph 6 requires that pointers to
different objects must not compare equal, and the dichotomy of
paragraph 3 therefore requires that they compare unequal.  It's up
to the implementation to get this right, whatever the memory
organization might be.

--



Sat, 10 Jan 2004 05:37:41 GMT  
 Comparing pointers to different objects

Quote:


> > We know that == and != are the only relational operators that are
> > defined when comparing pointers to two different objects.

> > But what if the system has two or more separate memory spaces and
> > each object is in its own memory space? Does such a system cease
> > to be conforming? Or is the implemntation required to provide some
> > magic trick to make such a comparison defined?

> The standard defines the comparisons of the address of different
> objects.  Any conforming implementation must follow this.  If it
> doesn't, then it's not conforming.  The implementation doesn't
> get a "this is hard to do, so you don't have to do it" free
> conformance card.

Err, thank you.
I realized immediately after posting that the obvious answer to my
compound question is: "Yes" :-)

--
Peter Pichler (Increment my "From:" address if your email bounces.)
This message is not solicitation for contact via email or phone.



Sat, 10 Jan 2004 05:45:34 GMT  
 Comparing pointers to different objects

Quote:

> The standard defines the comparisons of the address of different
> objects.  Any conforming implementation must follow this.  If it
> doesn't, then it's not conforming.  The implementation doesn't
> get a "this is hard to do, so you don't have to do it" free
> conformance card.

So the old "large" memory model used by DOS compilers  was
non-conforming?

IIRC, Intel 8086 processors (and 80x86 processors in real mode) can
address 1MB of memory, using a 16-bit segment and a 16-bit offset.  So
address = segment << 4 + offset.

An ugly consequence of this is the multitude of segment:offset
combinations that can point to the same address, and will compare as not
equal.
--
========================================================================

========================================================================



Sat, 10 Jan 2004 06:07:42 GMT  
 Comparing pointers to different objects


Quote:
>So the old "large" memory model used by DOS compilers  was
>non-conforming?

It conforms, or fails to conform, depending on whether it follows
the rules as long as you follow the rules first. :-)

Quote:
>IIRC, Intel 8086 processors (and 80x86 processors in real mode) can
>address 1MB of memory, using a 16-bit segment and a 16-bit offset.  So
>address = segment << 4 + offset.

>An ugly consequence of this is the multitude of segment:offset
>combinations that can point to the same address, and will compare as not
>equal.

So, suppose that you write:

    void *p, *q;
    p = <some expression>;
    q = <some other expression>;

    if (p != q) puts("different"); else puts("same");

Suppose further that this prints "different" even though p and q
point to the same C object (and not one-past-end-of-array and other
weird exceptional cases).

The only question now remaining is: were the two <expression>s
ordinary C expressions, or was one of them some weird extension?
If the expressions were:

    p = &objA;
    q = &objA; /* or q = p, etc */

and it prints "different", the implementation fails to conform.
On the other hand, if the expressions were, instead, something like
this:

    p = &objA;
    q = MAKE_POINTER(SEG(p) - 1, OFFSET(p) + 16);

where this did clever stuff with casts to and from "int", and it
prints "different" even though changing *q changes *p, then the
"failure to conform" is not the implementation's, but rather the
code's.  Since the code abandoned the C standard, the code can no
longer hold the implementation to that same standard.
--
In-Real-Life: Chris Torek, Wind River Systems




Sat, 10 Jan 2004 06:23:14 GMT  
 Comparing pointers to different objects


Quote:

> > The standard defines the comparisons of the address of different
> > objects.  Any conforming implementation must follow this.  If it
> > doesn't, then it's not conforming.  The implementation doesn't
> > get a "this is hard to do, so you don't have to do it" free
> > conformance card.

> So the old "large" memory model used by DOS compilers  was
> non-conforming?

> IIRC, Intel 8086 processors (and 80x86 processors in real mode) can
> address 1MB of memory, using a 16-bit segment and a 16-bit offset.  So
> address = segment << 4 + offset.

> An ugly consequence of this is the multitude of segment:offset
> combinations that can point to the same address, and will compare as not
> equal.

However, if the compiler never provided a way (without invoked Undefined
Behavior) to produce two different pointers (with different
segments/offsets) to the same object, they didn't have to worry about the
distinction -- comparing the bit patterns that made up the pointers always
gave the right results.  With the implementations I've seen, Lage model (as
opposed to Huge model) placed every object into precisely one segment and
never adjusted the segment value of any pointer, so there was no problem.

--
poncho



Sat, 10 Jan 2004 07:57:46 GMT  
 Comparing pointers to different objects

Quote:
>So the old "large" memory model used by DOS compilers  was
>non-conforming?

>IIRC, Intel 8086 processors (and 80x86 processors in real mode) can
>address 1MB of memory, using a 16-bit segment and a 16-bit offset.  So
>address = segment << 4 + offset.

>An ugly consequence of this is the multitude of segment:offset
>combinations that can point to the same address, and will compare as not
>equal.

There are ways out of this:

(1) Any two combinations of segment:offset *WILL* compare equal,
even if it requires "normalizing" the pointers (so that the offset
falls in the range 0-15) before doing the comparison (thereby making
pointer comparison expensive).

OR
(2) There is no conforming way to get hold of more than one
segment:offset that points at the same location.  This means limiting
object size to 65535 and carefully tracking what segment something
is in.  ANSI C allows a >=, >, <=, or < pointer comparison to be
done in 16 bits, as pointers you are allowed to compare (or generate
with pointer math) in that way have the same segment.

OR
(3) Objects larger than 64k are allowed, pointer comparisons involve
a 32-bit comparison, but all pointer arithmetic is required to
"normalize" the pointer before using it.  This is the "huge model"
approach.

                                        Gordon L. Burditt



Sat, 10 Jan 2004 09:38:25 GMT  
 Comparing pointers to different objects

Quote:


> > The standard defines the comparisons of the address of different
> > objects.  Any conforming implementation must follow this.  If it
> > doesn't, then it's not conforming.  The implementation doesn't
> > get a "this is hard to do, so you don't have to do it" free
> > conformance card.

> So the old "large" memory model used by DOS compilers  was
> non-conforming?

No, it just means that the comparison has to be performed by a
routine that normalizes the pointers before comparison.  This is
the implementors responsibility, not yours.

--

   (Remove "XXXX" from reply address. my-deja works unmodified)



Sat, 10 Jan 2004 10:30:51 GMT  
 Comparing pointers to different objects

Quote:
>We know that == and != are the only relational operators that are
>defined when comparing pointers to two different objects.

Some of us also know that == and != are NOT relational operators, they
are equality operators :-)

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Sat, 10 Jan 2004 12:39:53 GMT  
 Comparing pointers to different objects

Quote:


> > The standard defines the comparisons of the address of different
> > objects.  Any conforming implementation must follow this.  If it
> > doesn't, then it's not conforming.  The implementation doesn't
> > get a "this is hard to do, so you don't have to do it" free
> > conformance card.

> So the old "large" memory model used by DOS compilers  was
> non-conforming?

Technically, yes;  however,  Borland,  at least,  had a "huge" model that,
among other things,  did pointer comparisons on the full 20-bit hardware
address.

Quote:
> An ugly consequence of this is the multitude of segment:offset
> combinations that can point to the same address, and will compare as not
> equal.

This could be a problem in theory;  however,  as long as one didn't try to
do things like comparing the addresses of items in arrays returned by two
seperate calls to malloc(),  it should not have been a problem.  The only
limitiation in the "large' memory model was that no single array could be
larger than 64k;  that's what "huge" was really supposed to address.

Sorry if this is getting too platform-specific...

--
DLL



Sun, 11 Jan 2004 22:07:28 GMT  
 Comparing pointers to different objects

Quote:


> > > The standard defines the comparisons of the address of different
> > > objects.  Any conforming implementation must follow this.  If it
> > > doesn't, then it's not conforming.  The implementation doesn't
> > > get a "this is hard to do, so you don't have to do it" free
> > > conformance card.

> > So the old "large" memory model used by DOS compilers  was
> > non-conforming?

> Technically, yes; [...]

I doubt it, because I doubt that there was any way that a
strictly conforming program could get two different pointers to
the same address.  Such pointers only showed up when one used
compiler extensions or undefined behavior.
--
Available for short-term C and Linux contracts through September 2001.


Mon, 12 Jan 2004 00:32:24 GMT  
 Comparing pointers to different objects

Quote:

> I doubt it, because I doubt that there was any way that a
> strictly conforming program could get two different pointers to
> the same address.  Such pointers only showed up when one used
> compiler extensions or undefined behavior.
> --
> Available for short-term C and Linux contracts through September 2001.

Wandering a bit from the DOS context...

The MIPS SOC that I was working on in SJ used address lines to determine
whether or not the cache should be bypassed -- and this was reflected in
pointers. Two pointers to the same location would compare as != if one
were via cache and the other wasn't.

It kept life interesting. 8-)
--
Morris Dovey
West Des Moines, Iowa USA
Available for embedded C contract work



Mon, 12 Jan 2004 02:03:11 GMT  
 Comparing pointers to different objects

Quote:


>> > The standard defines the comparisons of the address of different
>> > objects.  Any conforming implementation must follow this.  If it
>> > doesn't, then it's not conforming.  The implementation doesn't
>> > get a "this is hard to do, so you don't have to do it" free
>> > conformance card.

>> So the old "large" memory model used by DOS compilers  was
>> non-conforming?

>Technically, yes;

Technically, not, because no strictly conforming program could generate
two pointers to the same object that had different representations.

Quote:
>however,  Borland,  at least,  had a "huge" model that,
>among other things,  did pointer comparisons on the full 20-bit hardware
>address.

Borland "inherited" the huge memory model from Microsoft.  The only memory
model supported by Borland but not found in Microsoft compilers was tiny.

Quote:
>> An ugly consequence of this is the multitude of segment:offset
>> combinations that can point to the same address, and will compare as not
>> equal.

>This could be a problem in theory;  however,  as long as one didn't try to
>do things like comparing the addresses of items in arrays returned by two
>seperate calls to malloc(),  it should not have been a problem.

What's the problem with the above scenario?  There is no way the two
addresses would compare equal in the large memory model.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Mon, 12 Jan 2004 04:05:15 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Passing pointers between objects created in different threads ?

2. Comparing 2 dates of different type

3. Binary compare of built executable is different

4. Frsutrated-CListBox And Compare (Different from others)

5. How do I compare to object types?

6. Comparing IPAddress objects

7. Comparing two CTime objects

8. comparing pointer and integer

9. Comparing void * pointers via unsigned char array

10. Help comparing pointer to unsigned int

11. Problem: Pointers as compared with Arrays

12. Comparing Pointers

 

 
Powered by phpBB® Forum Software