relational operators on pointers

[glen herrmannsfeldt]

The subject recently came up in comp.compilers, though I believe that
I asked here before.

If you use relational operators, other than == and !=, on
pointers to different objects, is there any requirement on
the result?


#include <stdio.h>
int main() {
char *one="one";
char *two="two";

if(one<two || one>two) printf("not equal\n");
else printf("equal\n");
}


Is it allowed to print equal?

This question comes up for systems such as JVM that consider object
references as opaque, and the offset must be kept separately. For
operators other than == and != I would only compare the offset part.

JVM has only equality test for object references.

-- glen

 

[Christian Bau]

The subject recently came up in comp.compilers, though I believe that
I asked here before.

If you use relational operators, other than == and !=, on
pointers to different objects, is there any requirement on
the result?


#include <stdio.h>
int main() {
char *one="one";
char *two="two";

if(one<two || one>two) printf("not equal\n");
else printf("equal\n");
}


Is it allowed to print equal?

This question comes up for systems such as JVM that consider object
references as opaque, and the offset must be kept separately. For
operators other than == and != I would only compare the offset part.

It invokes undefined behavior, so it can print anything. Or your
computer might explode.

Comparing pointers with <, <=, > or >= is only allowed if both point
into the same object.

 

[Fred L. Kleinschmidt]

The subject recently came up in comp.compilers, though I believe that
I asked here before.

If you use relational operators, other than == and !=, on
pointers to different objects, is there any requirement on
the result?

#include <stdio.h>
int main() {
char *one="one";
char *two="two";

if(one<two || one>two) printf("not equal\n");
else printf("equal\n");
}

Is it allowed to print equal?

This question comes up for systems such as JVM that consider object
references as opaque, and the offset must be kept separately. For
operators other than == and != I would only compare the offset part.

JVM has only equality test for object references.

-- glen

There is rarely any point in using relational operators other than "=="
and "!=" unless the pointers point to some primitive. Otherwise, you are
comparing addresses of structs or arrays, which would appear to you as
rather random, since you have no control over where the compiler places
them on creation.

In your example above, the only guarantee is that they are not equal,
since the two pointers point to different locations in memory.

 

[Chris Torek]

If you use relational operators, other than == and !=, on
pointers to different objects, is there any requirement on
the result?

No. (In fact, the C standard calls == and != "equality operators"
just so that it can separate them out from the <, <=, >, and >=
operators; and the only reason to do that is because the latter
four are undefined on pointers.)

This question comes up for systems such as JVM that consider object
references as opaque, and the offset must be kept separately. For
operators other than == and != I would only compare the offset part.

This has historical precedent in "large model" 80x86 C compilers,
which did precisely the same thing. I suspect those 80x86 C
compilers are the main reason the C standard says what it says.

(Now let's see if the .signature comes out at all this time...)

 

[Grumble]

It invokes undefined behavior, so it can print anything. Or your
computer might explode.

Do you know an ANSI-conformant way to make one's computer explode?

 

[Morris Dovey]

Do you know an ANSI-conformant way to make one's computer explode?

Install Windows 3.1 ?

 

[James Hu]

Do you know an ANSI-conformant way to make one's computer explode?

There is no such thing as an exploding computer in Standard C. Please
try a newsgroup more specific to your platform.

-- James

 

[Robert Stankowic]

No. (In fact, the C standard calls == and != "equality operators"
just so that it can separate them out from the <, <=, >, and >=
operators; and the only reason to do that is because the latter

^^^^^^^^^^^^^^^^^^

four are undefined on pointers.)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sorry, Chris, I don't get that.
I understand that you refer to pointers to different objects here, (if the
pointers point to the same object, these operators are well defined if I
understand 6.5.8 v2 of n869 correctly). But I cannot see a connection with
the reason you mention.

kind regards
Robert

 

[August Derleth]

Install Windows 3.1 ?

Install Windows XP and show it a Linux boot disk?

 

[Robert Stankowic]

Morris Dovey <[email protected]> wrote in message

Install Windows XP and show it a Linux boot disk?

Install Linux and show it an XP boot disk? <g, d&r>

 

[Randy Howard]

Do you know an ANSI-conformant way to make one's computer explode?

Assume a nuclear power plant is the device attached to stdout and
parses control rod positioning commands sent to it via the same. It
shouldn't be difficult in such a case to cause not only the
computer, but a large area surrounding it turn into a smoking hole.

 

[Kelsey Bjarnason]

Install Windows XP and show it a Linux boot disk?

I'd think the other way around would be more likely. "Oh, no! You're
*not* going to make me run *THAT* are you???"

 

[Ben Pfaff]

No. (In fact, the C standard calls == and != "equality operators"
just so that it can separate them out from the <, <=, >, and >=
operators; and the only reason to do that is because the latter
four are undefined on pointers.)

They are not undefined if the pointers point within a single
array. Another reason to separate them is that equality
operators and relational operators have different precedence.

 

[Dan Pop]

No. (In fact, the C standard calls == and != "equality operators"
just so that it can separate them out from the <, <=, >, and >=
operators; and the only reason to do that is because the latter
four are undefined on pointers.) ^^^^^^^^^^

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you sure? ;-)

They are undefined on pointers to different objects only.

Dan

 

[Chris Torek]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sorry, Chris, I don't get that.
I understand that you refer to pointers to different objects here, (if the
pointers point to the same object, these operators are well defined if I
understand 6.5.8 v2 of n869 correctly). But I cannot see a connection with
the reason you mention.

Perhaps it is best if I just say "it was late at night and I was
tired while testing the new trn"

The separation of the operators also gives them different binding
("precedence" in an operator-precedence grammar), so that:

p == q < r == s

parses as:

(p == q) < (r == s)

Hence the separation serves a number of purposes. I was just plain
wrong.

 

[Christian Bau]

Do you know an ANSI-conformant way to make one's computer explode?

I don't, but I wouldn't be surprised if there was an ANSI standard for
the use of explosives, so there is probably an ANSI-conforming way to
make a computer explode safely without the risk of injuring anyone. I
wouldn't know which newsgroup you would have to check if you are
interested.

 

[glen herrmannsfeldt]

Assume a nuclear power plant is the device attached to stdout and
parses control rod positioning commands sent to it via the same. It
shouldn't be difficult in such a case to cause not only the
computer, but a large area surrounding it turn into a smoking hole.

Usually they have interlocks that will guarantee that software can't
go too wrong. Unless the valve gets stuck open, or something
similar happens.

-- glen

 

[Mark McIntyre]

There is no such thing as an exploding computer in Standard C.

Nonsense. Invoke UB in a tight loop on an infinite number of computers
and /eventually/ one of them will explode.

 

[James Hu]

Nonsense. Invoke UB in a tight loop on an infinite number of computers
and /eventually/ one of them will explode.

Chapter and verse please!

-- James

 

[Mark McIntyre]

Chapter and verse please!

3.4.3 covers it nicely.