Array initialization

[sarathy]

Consider the code below.

char a[]="Hello";
char b[5]="Hello";



printf ("%d\n",sizeof(a));
printf ("%d\n",sizeof(b));

Output :
------------
6
5

According to the first initialization ,"Hello" is abbreviated as H e l
l o \0. Hence size is 6
But in the second expression i am able to manage the string hello in 5
bytes.
Does'nt the first case sound ineffecient when compared to the second
one.

Either the compiler must manage the \0 internally in both cases and
print 5.
Else allow the user to specify a size 1 greater than the actual
initializer length in the second case.
Why is this incompatibility???

Sarathy
:wq

 

[Richard Heathfield]

sarathy said:

Consider the code below.

char a[]="Hello";

a is an array of six char, containing the string "Hello".

char b[5]="Hello";

b is an array of five char, containing the characters 'H', 'e', 'l', 'l',
and 'o'. It does not contain a string, since there is no null character.

printf ("%d\n",sizeof(a));
printf ("%d\n",sizeof(b));

Output :
------------
6
5

According to the first initialization ,"Hello" is abbreviated as H e l
l o \0. Hence size is 6
Right.

But in the second expression i am able to manage the string hello in 5
bytes.

Wrong. It's not a string.

 

[Martin Ambuhl]

Consider the code below.

char a[]="Hello";
char b[5]="Hello";



printf ("%d\n",sizeof(a));
printf ("%d\n",sizeof(b));

Output :
------------
6
5

According to the first initialization ,"Hello" is abbreviated as H e l
l o \0. Hence size is 6

You might not want to use "abbreviated" in that sentence; it probably
doesn't mean what you think it does.
Yes, the declaration
char a[]="Hello";
is equivalent to
char a[] = {'H', 'e', 'l', 'l', 'o', 0 };
That is, a is an array initialized with the _string_ "Hello".

But in the second expression i am able to manage the string hello in 5
bytes.

No, that is incorrect. The initialization
char b[5]="Hello";
is equivalent to
char b[5] = {'H', 'e', 'l', 'l', 'o'};
That is, b is an array initialized with the _char_ values 'H', 'e', 'l',
'l','o'. There is no string in b; a string ends in a 0 byte. Indeed,
char b[5]="Hello";
if you had declared it with
char b[6]="Hello";
you _would_ have had a string, since the 6th byte would have been set to 0.

Does'nt the first case sound ineffecient when compared to the second
one.

Not a bit. A non-string char array like your b[5] cannot function as a
string.

Either the compiler must manage the \0 internally in both cases and
print 5.

What the hell does that mean?

Else allow the user to specify a size 1 greater than the actual
initializer length in the second case.

Why? The second declaration is of a char array of 5 bytes. For the
compiler to decide that you are an idiot who wanted 6 bytes would be
unwelcome arrogance.

Why is this incompatibility???

"Incompatibility" is a strong word. No, you cannot treat non-strings as
if they were strings. So what? No, char arrays should not be forced to
be strings.

 

[Mark McIntyre]

Consider the code below.

char a[]="Hello";
char b[5]="Hello";

Does'nt the first case sound ineffecient when compared to the second
one.

No. The second isn't a string - try strlen() or strcat() on it, and
you may be surprised (especially when not compiling in debug mode)..

Why is this incompatibility???

The first is a correctly formed string, the second is an array of
chars, which cannot be used a a string.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Consider the code below.

char a[]="Hello";
char b[5]="Hello";

Does'nt the first case sound ineffecient when compared to the second
one.

No. The second isn't a string - try strlen() or strcat() on it, and
you may be surprised (especially when not compiling in debug mode)..

Or, worse, you may not be surprised, even though you should be. There
could easily be a stray 0 byte just after b, which could mask the
error. Such are the vagaries of undefined behavior.

 

[Jonathan Lamothe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Consider the code below.

char a[]="Hello";
char b[5]="Hello";



printf ("%d\n",sizeof(a));
printf ("%d\n",sizeof(b));

Output :
------------
6
5

According to the first initialization ,"Hello" is abbreviated as H e l
l o \0. Hence size is 6
But in the second expression i am able to manage the string hello in 5
bytes.
Does'nt the first case sound ineffecient when compared to the second
one.

Either the compiler must manage the \0 internally in both cases and
print 5.
Else allow the user to specify a size 1 greater than the actual
initializer length in the second case.
Why is this incompatibility???

Sarathy
:wq

If you were to represent strings without the trailing '\0' character,
how would you know where they end? When you pass an array to a
function, you only get a pointer to the first element, but no indication
of the number of elements in the array.

- --
Regards,
Jonathan Lamothe

/*
* Oops. The kernel tried to access some bad page. We'll have to
* terminate things with extreme prejudice.
*/

die_if_kernel("Oops", regs, error_code);
-- From linux/arch/i386/mm/fault.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEw6a7q9nD47x87JYRAmzlAKCxRDRtNQlHuZImORdG1+VpdMKmVQCePQxZ
sATvBzWXJ+f4GZgk1B5pP9Q=
=Ux/t
-----END PGP SIGNATURE-----