String Comparison

[Dhruv Ahuja]

Consider:

printf("%d", "ABC" == "ABC");

The ANSI standard says that string comparsion using a comparison
operator (==) is not allowed. It recommends the use of the strcmp() in
<string.h>.

The Borland compiled programs print "0" on this; while the GCC and MS
VC++ compiled programs print "1".

Which compiler, would you say, returns the most appropriate answer,
not forgetting what the ANSI recommends...

 

[Joona I Palaste]

Consider:

printf("%d", "ABC" == "ABC");

The ANSI standard says that string comparsion using a comparison
operator (==) is not allowed. It recommends the use of the strcmp() in
<string.h>.

It certainly does not say it is not allowed. I think what it says is
that it will not necessarily yield the correct result based on the
strings' content.

The Borland compiled programs print "0" on this; while the GCC and MS
VC++ compiled programs print "1".

Which compiler, would you say, returns the most appropriate answer,
not forgetting what the ANSI recommends...

All. None. Pick one. Or more. All the ANSI standard specifies in this
regard is that if two strings have different contents, an == comparison
must return 0. If they have the same content, it might return either 0
or 1, completely depending on the implementation.

 

[Default User]

Consider:

printf("%d", "ABC" == "ABC");

The ANSI standard says that string comparsion using a comparison
operator (==) is not allowed.

Please quote the standard where it says this.

It recommends the use of the strcmp() in
<string.h>.

Yeah, if you want to get an answer that means what you think it does.

The Borland compiled programs print "0" on this; while the GCC and MS
VC++ compiled programs print "1".

The comparison you show checks the equality of two pointers. If a
particular compiler has reused the string literal, then indeed the
pointers will compare because they will be the same one. If it
generates a unique string for each literal, then they won't.

Which compiler, would you say, returns the most appropriate answer,
not forgetting what the ANSI recommends...

As the standard doesn't recommend anything for the case you show,
either is appropriate.


Brian

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

If it is, *I'd* be glad to hear of it. Wouldn't this require memory
behaving differently depending on which pointer it's accessed through?

"one\0two" and "one" might compare equal with some compilers/linkers.

 

[Mark McIntyre]

All the ANSI standard specifies in this
regard is that if two strings have different contents, an == comparison
must return 0.

Only by coincidence, since the values of the pointers to the two will more
or less have be different. I guess its possible to concieve of an
implementation or mechanism where this would not be true.

 

[Joona I Palaste]

Only by coincidence, since the values of the pointers to the two will more
or less have be different. I guess its possible to concieve of an
implementation or mechanism where this would not be true.

If it is, *I'd* be glad to hear of it. Wouldn't this require memory
behaving differently depending on which pointer it's accessed through?

 

[Dave Vandervies]

If it is, *I'd* be glad to hear of it. Wouldn't this require memory
behaving differently depending on which pointer it's accessed through?

Not allowed to happen. If two pointers compare equal, following them
will give you the same object, which has to have the same value whichever
pointer you use to get at it.

Note that this only applies to equality conversions - it's possible to
have two different pointers (to nonidentical strings, f'rexample) such
that ptr1<ptr2 and ptr2<ptr1 both evaluate to false (which if pointers
were well-ordered would imply that they were equal).
(This can happen in a fully segmented memory model where only the offsets
into the segment are used for inequality comparisons, which is valid
since pointer inequality comparisons are only defined on pointers into
the same object or array. Comparing for equal or not-equal doesn't have
this constraint and would be required to check both segment and offset,
coming back with not-equal in this case.)


dave

 

[Dave Vandervies]

"one\0two" and "one" might compare equal with some compilers/linkers.

Since we're talking about strings, which are defined as sequences of
non-'\0' characters terminated by a '\0' character, these are the same
string, so they're allowed to be pointed at by equal pointers.


dave

 

[Mark McIntyre]

If it is, *I'd* be glad to hear of it. Wouldn't this require memory
behaving differently depending on which pointer it's accessed through?

One trivial way to achieve this is to pass pointers between processes,
since the same logical address could map to different physical ones. This
is of course outside the realms of C.