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

Wron call stack + Locals data type

Hi everybody
I would like to know if it is possible to force Keil to display a specific type for a data in debugging mode in the call Stack + Local?

I have a parameter type which is a struct but Keil display data as an unsigned char * instead of my struct (which is a typedef fix size array of char).

Thanks.

Have a nice Day

Aurelien

  • So why not change the function to take a pointer to a struct then?

    If you really need to operate on the raw bytes of the struct, you can always typecast to an array inside the function.

    You want all calls to keep as much type information as possible - else you both hurt your debugging and you hurt the compilers ability to catch errors in the code.

  • my struct (which is a typedef fix size array of char)

    That description is self-contradictory. A typedef'ed array is not a struct.

  • "That description is self-contradictory. A typedef'ed array is not a struct."

    Unless it looks something like below and is both a struct and a fix-sized array of char:

    struct {
        char data[10];
    };
    

  • HI, thanks for your response,
    I write my message quickly,
    my data is :

    typedef unsigned char   MAC_48[6];
    

  • "I have a parameter type which is a struct but Keil display data as an unsigned char *"

    So exactly why should Keil _not_ show your data as unsigned char*?

  • Unless it looks something like below and is both a struct and a fix-sized array of char:

    It's not. That's a typedef'ed struct, but it's not an array. It contains an array, but that's significantly different from being one, the OP's case at hand being a prime example of a practical difference controlled by that distinction.

    Talking about programming constructs that sloppily is really not terribly helpful. Compilers are enormously picky about all the details of source code syntax and semantics. So we as programmers have to be similarly picky when talking about that stuff, or risk causing more confusion than clarification.

  • "Talking about programming constructs that sloppily is really not terribly helpful."

    No, but natural language can get away with it. Not everyone who comes here are very experienced with computer languages and their more strict definitions - quite a bit of sample code we tend to see clearly indicates that a number of posters treats the programming statements as some arcane magic where constructs are randomly combined trying to get past the compiler syntax checking (not to mention trying to get the expected runtime results).

    And not everyone is comfortable expressing themselves in English.

    Which means we may have to spend some time trying to dig a bit deeper to try to fully understand the intention of the original question.

    My example is a zero-data encapsulation of an array. So for someone not experienced in C/C++, or programming languages in general, it isn't unlikely to be seen as an array.