Why is the size of empty constant 1 byte ?

[radha gogia]

int main()
{
char ch="";
printf("%c %d",ch ,ch);
return 0;
}

I am getting diff answers in different compilers , so whats the reason behind this ?

Also when I write

printf("%d"sizeof(""))

;

then I get the output as 1 byte whats the reason behind this ?

[computerfox]

Try putting single quotes and a null value: \0.
Double quotes is usually saved for strings and you declared it as a char.

[radha gogia]

But then how is it working if I am giving double quotes?

[kiseitai2]

Maybe the compiler allocates a char array of about a byte and set the address of ch to array[0], which is the first character in the array? Does sizeof(ch) gives you 1? Does sizeof("") gives you 1 or 4? I am actually intrigued why the compiler wouldn't issue, at least, a warning about using a string literal (which is an array) in a char. I am not savvy on the details of the C and C++ language specifications so I do not know if the compilers are allowed to silently fix the problem for you since an array of "" also equals char. Let me reproduce your problem and I will respond back with a more concrete hypothesis!

[kiseitai2]

I ran the following program.

int main()
{
char ch="sad\0";
char ar[10] = "sad\0";
char* x = malloc(10);
printf("%d",sizeof(ch));//Outputs actual size of ch
printf("%s", "\n");
printf("%d %x", ch, &ch);//Outputs integer representation of ch's contents, hexadecimal value of address of ch
printf("%s", "\n");
printf("%s %x %d %x %x", ar, ar, sizeof(ar), &ar[0], &ar);//Outputs string, hexadecimal representation of ar (actually, address), actual size of ar, hexadecimal of address of 1st character in array, hexadecimal of address of array
printf("%s", "\n");
printf("%d", sizeof(""));//Outputs 1 because "" is an array of size 1
printf("%s", "\n");
printf("%d", sizeof(x));//Outputs 4 because x is an array allocated in the heap (type pointer which is of size 32bits or 4 bytes)!
return 0;
}

Results:

1. Your program had a small bug. Passing ch directly to printf without a call to sizeof() was outputting the address in RAM, which is expected to change.
2. I transiently forgot that arrays on the stack have known sizes so this will also change but only according to char array size! Thus, a char array of size 10 will output 10 when I use sizeof()! I confirmed this by comparing this output to the output of sizeof() on an array allocated on the heap of actual size 10!
3. It seems the compiler never assigns any portion of a string literal to the ch variable, since it outputs the ascii value of a random character that is not in the string literal!

I hope this helps!

[donbock]

... = "";
This defines an empty string consisting of only the null-termination. That is, the string consists of one char.

Line 3 should provoke a compiler error.
Either of the following variations are legal:

char ch[] = "";
char *ch = "";

In the first of these, ch is a 1-element char array. sizeof(ch) is 1.

In the second, ch is a pointer to a 1-element char array. sizeof(ch) is the implementation-specific size of a data pointer.

However, the compiler may insert pad bytes either to allow for faster access or to insure proper alignment of the next variable. I'm not sure, but I think whether or not pad bytes are included in the sizeof value is implementation-specific.

[kiseitai2]

I would agree that line 3 should provoke a compiler error, but gcc allows this syntax (char c = "";). However, the content of ch is not the first character in the array, which is the least behavior I would expect. ch always yields 36 in the test program I made. Why does gcc allows a blatantly wrong syntax and doesn't do anything related to what the syntax is trying to convey? It baffles me...

[weaknessforcats]

Fix this error first:

char ch="sad\0";

ch is a char. "sad\0" is the address of element 0 of a char[5]. If your compiler does not burp on this, get a better compiler.

Before pulling your hair on arrays, I recommend reading: http://bytes.com/topic/c/insights/77...rrays-revealed

Then post again.

[kiseitai2]

Don't get me wrong. I understand arrays. I simply reproduced the sample posted by the opener with some modifications to confirm this behavior and yes gcc accepts the syntax without giving an error. It throws a mild warning (warning: initialization makes integer from pointer without a cast [enabled by default]). I figured out what gcc is doing behind the scenes. It takes the address of the array and recast it as a char which means it throws away 3 of the 4 bytes. It's quiet an interesting behavior. Don't believe me? Try it yourself and you will see what the person actually asking saw. Regardless, the opener had a bug in his/ her program logic that has little to do with the char syntax and all to do with not calling sizeof on the variable to get the size of the type rather than the contents of the variable.
Culprit:

printf("%c %d",ch ,ch);

Should be:

printf("%c %d",ch ,sizeof(ch));

On the argument of &ar[0] == &ar, that's what I demonstrate to the opener with

printf("%s %x %d %x %x", ar, ar, sizeof(ar), &ar[0], &ar);

On the get a better compiler remark, welcome to Linus Torvalds' club. In all seriousness, I have plenty of compilers to fiddle around, I just picked the first one I had in front of my eyes for the experiment.

Oh yes, I read your article on arrays about 6 years ago and was going to link it if the opener was curious about why I hypothesized that char would get assigned the first character of the array "" after being allocated. Little did I know gcc was doing more nefarious things under the scenes (maybe that's why Google is so fond of Clang). Hey, at least, the scientific method works.

[donbock]

@kiseitai2, the behavior you describe is what you might expect from casting a pointer value into a char. That's a clue to what is happening. The compiler creates the initializer array somewhere in memory (just as it would if ch were a char*) and then assigns the address of that array to ch via an implicit cast. Probably.

I say might expect because casting a pointer into a char is at best implementation-defined behavior, and at worst undefined behavior. I'm not going to bother to look up which it is.