This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compilation changes values?

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.

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

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

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

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