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.
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.