Compilation changes values?

I really doubt that code values change from a tool malfunction. If you have any compile/link warnings get rid of them first.

a) I have, occasionally when a working session got too long, 'forgotten' the possibility that the location of variables may change.
b) If you link w/o debug info and load, some ICEs 'remember' where things were and THAT has 'delayed' me a few times. A REALLY nasty one I remember was that after loading a new totally different code, which happenbed to have a variable of the same name, the location, of that variable, was that of the former code.
c) are you looking at the values when the pointer is in scope?
d) continue this train of thought

Long debugtging sesssions tend to make problems appear that do not exist :(

Erik

Thanks for your help.

This is one of the variables:

uint code Default_Zk[8]=
{
        INIT_ZK_UART_ERR,       // 1
        INIT_ZK_UART_LIMIT,     // 5
        INIT_ZK_GETSTATUS,      // 3
        INIT_ZK_PUTACTVALS, // 12
        INIT_ZK_MULTISTEP,      // 5
        INIT_ZK_INKR_SENSE,     // 3
        INIT_ZK_REFR_DISPLAY,   // 3
        INIT_ZK_POWERFAIL       // 100
};

The values of the defines are written in the comments, to show what the values should look like.

This is what the make file says for the variable:

C:642EH PUBLIC Default_Zk

And this is what Hitop shows me:

i30.tinypic.com/2ql5zsn.jpg

after it auto-loaded the compiled file.

... a few things to check:

Have you checked the Hex file?

If you load the Hex file into the Keil simulator, is it OK?

Can you find your data elsewhere in CODE space?

Are you sure that you're not somehow getting the Hex file out-of-step with the build...?

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.

@Andy:
I can't load it into the simulator, because we have no license for the debugger.

Can you reproduce the problem in a sample that will fit within the limits of the evaluation debugger?

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.