String literals containing "\ 0" - why are they not the same?

Question

So, I did the following test:

char* a = "test"; char* b = "test"; char* c = "test\0"; 

And now the questions:

1) Is it guaranteed that a==b ? I know I'm comparing addresses. This is not intended to compare strings, but are string literals identical in the same memory location?

2) Why not a==c ? Can't the compiler see that they are on the same line?

3) Is an extra \0 added at the end of c , although it already contains one?

I did not want to ask three different questions for this, because they seem to be somehow connected, excuse me for that.

Note. The tag is correct, I'm interested in C ++. (although please indicate if C behavior is different)

Answer 1

Is it guaranteed that a == b?

No. But this is permitted in §2.14.5 / 12:

Are all string literals defined (i.e., stored in objects with non-overlapping objects). The effect of trying to change a string literal is undefined.

And as you can see from this last sentence, using char* instead of char const* , this is the recipe for the problem (and your compiler should reject it, make sure you have warnings and a high level of compliance is selected).

Why not? Can't the compiler see that they are on the same line?

No, they are not required to refer to the same array of characters. One has five elements, the other six. An implementation may store two in overlapping storage, but this is not required.

Is the optional \ 0 added at the end of c, although it already contains one?

Yes.

Answer 2

1 - absolutely not. a might == b, though, if the compiler decides to use the same static string.

2 - because they DO NOT belong to the same line

3 - yes.

The behavior here is no different from C and C ++, except that C ++ compilers must reject a non const const char * assignment.

Answer 3

1) Is it guaranteed that a == b?

This is not true. Please note that you are comparing addresses and they may point to different locations. Most smart compilers discard this repeating literal constant, so pointers can be compared with equals, but again not guaranteed by the standard.

2) Why not == c? Can't the compiler see that they are on the same line?

You are trying to compare pointers, they point to different places in memory. Even if you compared the contents of such pointers, they are still unequal (see the next question).

3) Is an extra \ 0 added at the end of c, although it already contains one?

Yes there is.

Answer 4

First of all, note that it must be const char * as that string literals break up.

• Both create arrays initialized with 't' 'e' 's' 't', denoted by the letter '\ 0' (length = 5). Comparing for equality, you will only say whether they will start with the same pointer, and not if they have the same content (although logically these two ideas follow each other).
• A is not equal to C because the same rules apply: a = 't' 'e' 's'' t '' \ 0 'and b =' t '' e '' s' 't' '\ 0' '\ 0 '
• Yes, the compiler always does this, and you should not do this explicitly if you create such a string. However, if you compiled an array and manually filled it, you need to make sure that you added \ 0.

Note that for my # 3, const char [] = "Hello World" will also automatically get \ 0 at the end, I returned to manually populating the array without having a compiler. / P>

Answer 5

The problem here is that you are confusing the concepts of pointer and text equivalence.

When you say a == b or a == c , you ask if the pointers point to the same physical address. The test has nothing to do with the textual content of pointers.

To get text equivalence you should use strcmp

Answer 6

If you are doing pointer comparisons than a! = B, b! = C, and c! = A. If the compiler is smart enough to notice that your first two lines are the same.

If you do strcmp (str, str) then all your lines will return as matches.

I'm not sure that the compiler will add an extra null value for c, but I would suggest that it will.

Answer 7

As mentioned several times in other answers, you are comparing pointers. However, I would add that strcmp(b,c) must be true because it stops checking the first \0 .