null char in c

[rola248]

hi,
I have this code,why is the displayed result "false"?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
{
   char name[6]="MEHMET"; /* 6 characters */
   char name1[6]="MEHMET";
if (strcmp(name,name1) == 0){
printf("true");
}else{
printf("false");
}
return 0;
}

[JosAH]

Change that to:

char name[7]="MEHMET"; /* 6 characters */ 
char name1[7]="MEHMET";

That leaves room for the trailing '\0' characters that terminate strings.

kind regards,

Jos

[unauthorized]

Or better yet, you can just use this form:
char my_string[] = "the compiler will determine this string's size";

This way, you will not have to worry about knowing the actual string size as long as you don't plan on changing the string during runtime. Even better if you make it a "const char" for added safety.

[rola248]

thanx,but why it doesn't work when i use 6 for both arrays?i mean they both don't end with the null char so why aren't they equal??

[drhowarddrfine]

Since there is no terminating zero, the comparison continues past the end of the array until a zero is reached somewhere, but you don't know what data is after the last char in that array and it doesn't match so it returns false.

[unauthorized]

A character string in C has one extra NULL character after it's normal contents. In an array form, a string called "hello" would have the elements 'h', 'e', 'l', 'l', 'o' AND '\0'.
Google up "NULL terminated strings" if that doesn't make sense to you.

[Banfa]

The most likely cause that the 7 characters ('M', 'E', 'H', 'M', 'E', 'T' and '\0') of the 2 strings are writen sequencially in memory. Note that the C compiler will write 7 characters to the given address even though you have only provided arrays of length 6.

That means that in both cases you write 1 more character than the array holds or to put it another way you write outside the array bounds. Writing outside the array bounds is undefined behaviour.

Since you program invokes undefined behaviour anything could happen, there is no point continuing or trying to explain what is happening.

However assuming you ignore my last statement and continue then like I say those 2 arrays probably appear sequencially in memory. It allocates them and then writes 'M', 'E', 'H', 'M', 'E', 'T' and '\0' to the first one. Note the '\0' is written outside the bounds of the array and inside the next variable so when the next array is written the first 'M' overwrites the '\0' of the first array. You end up with the memory contents:

'M' 'E' 'H' 'M' 'E' 'T' 'M' 'E' 'H' 'M' 'E' 'T' '\0'

Note the presence of only 1 zero terminator, one of the strings will appear to have the contents to both to a function like strcmp.

Also note this is all conjecture, I have seen it happen on 1 system but like I said originally undefined behaviour has been invoked, anything could happen.

[JosAH]

The most likely cause that the 7 characters ('M', 'E', 'H', 'M', 'E', 'T' and '\0') of the 2 strings are writen sequencially in memory. Note that the C compiler will write 7 characters to the given address even though you have only provided arrays of length 6.

That means that in both cases you write 1 more character than the array holds or to put it another way you write outside the array bounds. Writing outside the array bounds is undefined behaviour.

That is not true, e.g. the following code snippet stores only 2 chars in the array:

char array[2]= "foo";

I don't have the Standard with me right now but it explicitly mentions this behaviour.

kind regards,

Jos

[Banfa]

That is not true, e.g. the following code snippet stores only 2 chars in the array:

DOH ! :D Apart from the fact that it is always a mistake to try and analyse undefined behaviour I perhaps should have qualified all of that with the platform on which I observed that behaviour (I certainly intended to) and that that was just my interpretation.

Thanks for the catch Jos, I guess the important point of this is that you should always make sure your arrays are large enough to hold the data you are putting in them and that particularly when calculating the size of a character array tohold a zero terminated string that you don't forget to include space for the zero terminator.

[Troy Martin]

It's best to do const char* name = "MEHMET"; instead, as it adds the trailing '\0' and it's good practice to not play with implicit casts when you're not sure what might happen :)

[unauthorized]

It's best to do const char* name = "MEHMET"; instead, as it adds the trailing '\0' and it's good practice to not play with implicit casts when you're not sure what might happen :)

In that way, you will be holding a pointer to the statically allocated character array and not the array itself. While syntax while there are no differences, the C standard makes no notion of how this should be handled and may, among other things make it less likely for the compiler to optimize your code. Any literal string has "\0" at the end unless you manually init the array character by character, which is why there are no (functional) differences to using this over const char name[] = "MEHMET";.
In fact, your code does have an implicit cast from char[] to char*. On the other hand, I'm almost certain that the C/C++ standards state that all string literals must always exist during runtime, so this form should not cause any errors unless you use this var in some static external object/var.