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.
Meanwhile I found out that from a certain address on, the values for the variable compared to their addresses are shifted by -16 bytes. Means, if the variable should start at 0x642E, the dedicated bytes start at 0x641E.
Have you checked the Hex file?
Problem solved. This was the type of problem that shouldn't happen. I declared a string
static uchar code Init_Utext[17] = 0;
and initialised it to be empty. But the compiler actually only put 1 byte into code space, though it should have been 17 and thus subsequent bytes where shifted -16 bytes. I call this a compiler bug, because it should be the same like
static uchar code Init_Utext[17] = "";
call this a compiler bug, because it should be the same...
I don't think the compiler should have accepted your original line at all.
"" is a special short-form for initializing a character array.
But to my knowledge, you may nevver initialize any form of array with =0. Either { value(s) } or (in some special cases) "string".
It is only when you work with string pointers, that you may initialize them with
char* ptr = 0; char* ptr = ""
in which case 0 is a null pointer.
you may never initialize any form of array with =value. Either { value(s) } or (in some special cases) "string".
That's right - the braces are required, except in the special case of "string".
Which does beg the question of why the compiler didn't report this as an error...?
Even if the braces were used, and too few initialisers supplied, the compiler should not reduce the explicitly-stated size of the array.
So there does seem to be a fault somewhere in the compiler...
"I declared a string"
remember that 'C' does not have a specific string type as such - all so-called "string handling" in 'C' is really just a convention using standard char arrays...
An array and a pointer are so very, very interchangeably similar in C (and most of the time in C++).
Somehow, the compiler seems to have confused a string array with a string pointer, and for some reason done half it's work based on a pointer, and half it's work based on a string array.
Correct - I should have written char array and char pointer in the above post, to avoid any confusion.
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.