Hello!
Suddenly we have problems with variables that are located in CODE space. We declare them with 'uint code varname[8] = {value1, value2,..etc.}'. The normal way.
After compilation we load the HEX file into HiTop. If I then look into the code space where the variables are located, the values are changed.
The C51 compiler config was not changed and this hasn't happen before.
Any clue? We are desperate. After years of using Keil C51 package and Hitex Hitop 4.11 with DProbeHS we never had such an error.
TIA.
Sorry guys, you are right. In your own way.
But the problem is to know what I should and what I shouldn't. There are no specific rules how to initialise a char array (=string, if it has EOL). From my logic, = 0 and = "" are the same. In both cases, the compiler should produce an array, initialised with 0. What's a compiler for, if not helping the programmer a little? C is circumstancial enough, so I don't want to block-init every single byte of the array.
Not sure what you are trying to say.
There are no specific rules how to initialise a char array (=string, if it has EOL). From my logic, = 0 and = "" are the same. In both cases, the compiler should produce an array, initialised with 0.
Have you read chapter 6.7.8 of the ISO/IEC 9899:1999 standard?
Please focus specifically on points 14, 15 and 16 which regulates semantics:
14: An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array.
15: An array with element type compatible with wchar_t may be initialized by a wide string literal, optionally enclosed in braces. Successive wide characters of the wide string literal (including the terminating null wide character if there is room or if the array is of unknown size) initialize the elements of the array.
16: Otherwise, the initializer for an object that has aggregate or union type shall be a braceenclosed list of initializers for the elements or named members.
Basically, the following holds:
- The general case is: array initializers do require curly braces.
- The special case: a character array can be initialized using a character string literal.
- An array can not be initalized with null.
Yes, there are - see Per's post.
"(=string, if it has EOL)"
"EOL" = "End Of Line"? ie, CR and/or LF - depending on the implementation?
No, EOL does not make a string!
It's the NUL-termination that makes it a so-called "string".
"From my logic, = 0 and = "" are the same"
Unfortuately, the compiler works to the ANSI spec, and not to your logic!
"In both cases, the compiler should produce an array, initialised with 0."
No, it shouldn't - see Per's post, again: If you want to individually initialise the elments of the array, then you must use braces!
char array[N] = "";
is equivalent to
char array[N] = { 0 };
"What's a compiler for, if not helping the programmer a little?"
Yes - but you have to work within the syntax and semantics rules of the language!
"C is circumstancial enough"
What's that supposed to mean?
"I don't want to block-init every single byte of the array."
You don't have to - see above.
I don't want to block-init every single byte of the array.
this is totally crazy
If you can document a valid purpose for an array in code memory that is not fully initialized, I'd be astonished.
Erik
"If you can document a valid purpose for an array in code memory that is not fully initialized, I'd be astonished."
Interesting point.
However, the 'C' standard does guarantee that the whole array will be initialised if you supply too few explicit initialisers - the "extras" will be zero.