Comparing char * with string literal

[subramanian100in]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters. So shouldn't the compiler
generate an error/warning for this comparison ?

 

[bytebro]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters. So shouldn't the compiler
generate an error/warning for this comparison ?

Why? It is pretty much equivalent to

if (address1 == address2)...

which is fairly obviously OK.

 

[Chris Dollin]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters. So shouldn't the compiler
generate an error/warning for this comparison ?

It's not required to generate a disgnostic. A good warning
for this wouldn't look like the one you're thinking of.

In the expression `a == "string"`, the literal is evaulated
in what I shall call "value" context, as opposed to "target of
assignment" context [1] or "operand of sizeof" context.
Remember that a string literal denotes an array, and that an
array in value context decays into a pointer to its first
element.

So we're comparing `a`, which is a pointer-to-char, to the
address of the `s` in `"string"`, which is pointer-to-char.
No problem, no diagnostic. Happy times!

But [2] ... this is a pretty useless comparision, and not just
because we know that `a` points to a different string; it's
worse than that, Jim.

The only way for the comparision to be true is if `a` points
to that very same `s`. Can it? At first glance no, because
there's no other variable referring to that `s`, and no
other path to get to that literal. So perhaps the compiler
should warn "comparision can never succeed"? Again no: suppose
we had

char *a = strchr( "long string", 's' );

so that it points to the `s` in "long string". The compiler
is /permitted/ to have the literal "string" share store with
the tail of "long string".

So the warning might be something like

"that comparision doesn't have a stable result, because
it depends whether whatever `a` points to is part of
some string literal somewhere in this program that ends
with `string`. I suggest you don't do that. Maybe you
should be using `strcmp`?"

And you have to rush out and buy a bigger monitor.

[1] Which I'd call "lvalue" context except I'd risk confusion
and a flame war.

[2] You knew I was going to say that.

 

[Sheth Raxit]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters. So shouldn't the compiler
generate an error/warning for this comparison ?

why ?
strings is an array of characters (terminating with \0 ),
arrays are having base address,string's base address points to its
first char

you are comparing char * to char * (assume we are not talking about
const)


--Raxit

 

[Richard Heathfield]

(e-mail address removed), India said:

Suppose we have

char *a = "test message" ;

Better: const char *a = "test message";

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters.

Yes, it is. But it is being used in a value context, and so the address
of its first element is used instead. That address is compared to the
address stored in a. If those addresses are the same, then == will
yield 1 as its result. If the addresses are different (regardless of
the similarity or otherwise of the objects pointed to), then == will
yield 0 as its result.

So shouldn't the compiler
generate an error/warning for this comparison ?

No.

 

[Eric Sosman]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters. So shouldn't the compiler
generate an error/warning for this comparison ?

No, because the comparison is perfectly legal. One
can even imagine a scenario where it would "work," such as:

#define YES "Da"
#define NO "Nyet"
const char *decision = NO;
if (this && that && moonPhase() == MOON_FULL)
decision = YES;
doSomething();
if (decision == YES) /* here it is ... */
doMore();

Personally, I would not use strings this way; it's really
using the pointers and not the strings themselves. But
it *is* a legal usage, and the compiler must not reject
the program because of it.

 

[Chris Dollin]

No, because the comparison is perfectly legal. One
can even imagine a scenario where it would "work," such as:

#define YES "Da"
#define NO "Nyet"
const char *decision = NO;
if (this && that && moonPhase() == MOON_FULL)
decision = YES;
doSomething();
if (decision == YES) /* here it is ... */
doMore();

A compiler that allocated fresh store for each new string
literal (that's allowed, right?) would be such that
`decision == YES` would never be true.

 

[Eric Sosman]

Chris Dollin wrote On 03/08/07 08:43,:

Eric Sosman wrote:




A compiler that allocated fresh store for each new string
literal (that's allowed, right?) would be such that
`decision == YES` would never be true.

<fx: self-administered dope slap> Yes, of course. It's
been so long since I used a compiler that *didn't* combine
identical literals (and sometimes "suffix literals," too)
that I clean forgot about it.

The code snippet remains legal, but is even stupider
than I thought when I wrote it. (It begins to challenge
my own personal stupidity level ...)

 

[Mike Wahler]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters.

Here, evaluation of the expression "string" evaluates
to the address of the character 's'; this value has type
'char *'.

The type of 'a' is also type 'char *'.

So shouldn't the compiler
generate an error/warning for this comparison ?

No. You're comparing two objects of the same type.

-Mike

 

[Malcolm McLean]

Suppose we have

char *a = "test message" ;

Consider the comparison

if (a == "string")
.....

Here "string" is an array of characters. So shouldn't the compiler
generate an error/warning for this comparison ?

The language doesn't always do what a programmer familiar with other
languages would expect.
Here the comparison is so unlikely to be a genuine piece of useful code that
a warning is justified, however the compiler writer needs to remember and
put in a special patch just for this situation. Justifiable for a big
compiler, but not for a cheapo one.

There is a similar issue with if( x = 1)
The problem is that constructs like

while( ch = *ptr++ )

are idiomatic and arguably a good thing because they reduce the line count.