• AVR Freaks

Hot!Pointer not initialized (correctly?)

Page: 1234 > Showing page 1 of 4
Author
Cyber
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2007/07/02 10:48:55
  • Location: 0
  • Status: offline
2019/08/23 08:58:26 (permalink)
0

Pointer not initialized (correctly?)

I have just upgraded to XC8 v2.10.  It is set to c90.  When I clean compile and run, my OLED screen is blank. I traced it to a problem with "oled_buf_start", which just points to the second byte of another buffer and is defined as:
 
uint8_t oled_buf[ OLED_BUF_SIZE + 1 ];
uint8_t *oled_buf_start = oled_buf + 1;
 
The assignment "oled_buf_start = oled_buf + 1" does not seem to take effect.  If I declare "oled_buf_start" in the same place, but do the assignment as the very first thing in my main, it works, showing it's not my code causing corruption.  Alternatively, if I switch back to compiler v1.45 and c89, it also works.
 
Any explanation?  Is this a v2.10 compiler bug?
 
#1

73 Replies Related Threads

    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11285
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/08/23 12:07:43 (permalink)
    +2 (2)
    You haven't given us much to go on;  "does not seem to take effect" doesn't tell us much.  Have you looked at the pointer in the debugger to see if it has the right value?
     
    As always, the best thing to do is create a minimal project that shows the problem and that anyone can compile.
    #2
    Cyber
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2007/07/02 10:48:55
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 01:54:48 (permalink)
    0
    Apologies for the delay.  I have run into the same problem once more and have done a bit more digging this time.  Find below the offending data structures.
     
    For some background, the code was working fine until I added "const char *units".  The first thing that went wrong was that a bit of code that's been compiling without problem suddenly can't be compiled.  "Code cannot be generated for..."  The line being: "menu->index += ( ctrl_count - ctrl_count_prev )".  As before, I split the line up until it compiled.  I don't see why it should be affected by the extra variable declared, but there we are.
     
    The real problem here is that the definition of <menu_main> failed to set the pointer to <menu_main_items> correctly.  Using the debugger I found that <menu_main_items> was at 0x543, but the pointer to in <menu_main> was 0x43, so the high byte is gone.  The mystery continues.
     
    In the code I manually assigned the pointer <menu_main>->items to <menu_main_items> and this worked.  But running the debugger, I find, curiously, that now it assigns the pointer correctly during definition, before my manual assignment.  In this case <menu_main_items> is at 0x4BF.
     
    The following observation is very non-specific, but possibly useful.  I have also found that by adding bits of code and/or variables, the problem goes away, as if it's an odd/even or alignment issue.  But it's an 8-bit PIC, so can't be alignment.
     
    I hope that helps you help me.
     
    ---------------------------------
     
    typedef enum
    {
    MENU_BACK,
    MENU_SUBMENU,
    MENU_VAR,
    MENU_SCREEN,
    } E_MENU_ITEM_TYPE;
     
    typedef struct menu_item_struct
    {
    E_MENU_ITEM_TYPE type;
    const char *text;
    const char *units;
    void *ptr; // submenu or variable pointer
    uint8_t var_id;
    } menu_item_t;
    typedef struct menu_struct
    {
    menu_item_t *items;
    int8_t items_len;
    struct menu_struct *prev;
    int8_t index;
    int8_t offset;
    } menu_t;
     
    menu_item_t menu_main_items[] =
    {
    { MENU_BACK, "BACK", "", NULL, STORE_NONE },
    { MENU_SUBMENU, "SETTINGS", "", &menu_settings, STORE_NONE },
    { MENU_SCREEN, "STATUS", "", NULL, MENU_SCREEN_STATUS },
    };
     
    menu_item_t menu_settings_items[] =
    {
    { MENU_BACK, "BACK", "", NULL, STORE_NONE },
    { MENU_VAR, "LOAD RATING", "A", NULL, STORE_HEAT_RATING_AMP },
    { MENU_VAR, "BATT ALLOWANCE", "A", NULL, STORE_BAT_ALLOWANCE_AMP },
    { MENU_VAR, "WAKE CURRENT", "A", NULL, STORE_START_CURRENT_AMP },
    { MENU_VAR, "CURRENT LIMIT", "DAC", NULL, STORE_CURRENT_LIMIT_AMP },
    };
     
    menu_t menu_main = { menu_main_items, MENU_ITEMS_COUNT(menu_main_items), NULL, 0, 0 };
    menu_t menu_settings = { menu_settings_items, MENU_ITEMS_COUNT(menu_settings_items), NULL, 0, 0 };
     
    #3
    rjc101
    Super Member
    • Total Posts : 107
    • Reward points : 0
    • Joined: 2016/07/08 14:56:34
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 02:28:58 (permalink)
    +1 (1)
    Just in case this is relevant to you...
     
    If you are calling functions via pointer, and those functions call sub-functions, there is nasty bug in XC8 where it allocates variables in the sub function to the same memory as the calling function.  Much fun is created as a result.  As far as I can see it isn't fixed in the current release (v2.10). Its bug XC8-1775
     
    https://www.microchip.com/forums/m1064058.aspx
     
    #4
    Cyber
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2007/07/02 10:48:55
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 02:44:43 (permalink)
    0
    Thanks for the heads-up.  This does look suspiciously similar.  Hmm...
     
    I don't have time to analyze whether I might be having the same problem as my fix appears to work, but if I get stuck again, I might have to.
    #5
    rjc101
    Super Member
    • Total Posts : 107
    • Reward points : 0
    • Joined: 2016/07/08 14:56:34
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 02:54:13 (permalink)
    +2 (2)
    The quick way is to check the .map file, search for the function and check the variable addresses, then check the sub-function and it's variables memory addresses.  They should not overlap.  As you add or remove code or variables the problem can come and go.
     
    I thought I was debugging simple memory corruption.  It was corruption, but not one of my own making. It took a LONG time to find.
    #6
    Cyber
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2007/07/02 10:48:55
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 03:09:46 (permalink)
    0
    These are the hardest problems to find!  99% of the time you think it's a compiler problem it is not, but when it is, it's unbelievably hard to find.
     
    In my case I'm not using pointer functions and it does look like it just chopped off the pointer high byte, so may not bet he same issue, despite the similarity.  The source and target pointers are in different banks, though.  I haven't figured out how to edit the linker files or put data in particular memory areas with XC8 yet.  I used to do this all the time with the old compiler and often solved these kinds of issues.  Many of the old #pragmas no longer work.
     
    #7
    Jan Audio
    Starting Member
    • Total Posts : 80
    • Reward points : 0
    • Joined: 2018/09/24 08:12:24
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 06:29:08 (permalink)
    -1 (1)
    In XC8 you have to use a init function, i got used to it, still dont like XC8 in many things.
    #8
    ric
    Super Member
    • Total Posts : 23545
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Pointer not initialized (correctly?) 2019/09/02 06:55:56 (permalink)
    +2 (2)
    Jan Audio
    In XC8 you have to use a init function,

    What does this mean?
     

    ... still dont like XC8 in many things.

    Why?
    Because it forces you to write ANSI standard code?

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #9
    NorthGuy
    Super Member
    • Total Posts : 5574
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 08:23:39 (permalink)
    +2 (2)
    @OP: I suggest reporting the bug to Microchip. This will give them a chance to fix it.
     
    In XC8, the actual size of the pointers is empirically selected based on usage. My guess is that this is not handled correctly with your "not so common" initializations.
    #10
    Cyber
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2007/07/02 10:48:55
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 12:15:40 (permalink)
    0
    Does Microchip not read these forums to identify bugs?
     
    Where do I officially report bugs?
    #11
    ric
    Super Member
    • Total Posts : 23545
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Pointer not initialized (correctly?) 2019/09/02 13:13:08 (permalink)
    +1 (1)
    Cyber
    Does Microchip not read these forums to identify bugs?

    No.
    Some employees do look in their own time, but it's unofficial.
     

    Where do I officially report bugs?

    Via a "Support Ticket"
    http://microchip.com/support
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #12
    LdB_ECM
    Senior Member
    • Total Posts : 144
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 19:21:31 (permalink)
    -1 (1)
    Sorry the second line of code is junk it isn't a compiler bug, different compilers based on promotion could do different things with that.
    uint8_t oled_buf[ OLED_BUF_SIZE + 1 ];
    uint8_t *oled_buf_start = oled_buf + 1;

    A guess at what you are trying to do which doesn't have promotion involved
    uint8_t *oled_buf_start = &oled_buf[1];

    post edited by LdB_ECM - 2019/09/02 19:24:49
    #13
    ric
    Super Member
    • Total Posts : 23545
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Pointer not initialized (correctly?) 2019/09/02 19:40:31 (permalink)
    +1 (1)
    Adding an integral value to a pointer is perfectly valid.

    Adding an integral value to a pointer results in another pointer of the same
    type. Adding n gives a pointer which points n elements further along an
    array than the original pointer did.

    I can't see anything wrong with "uint8_t * oled_buf_start = oled_buf + 1"
    (apart from it appearing to waste the first location in the array.)
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #14
    LdB_ECM
    Senior Member
    • Total Posts : 144
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 20:54:02 (permalink)
    -1 (1)
    The promotion is to an integer AKA it can be negative or not even same range as a pointer and then you add one ... you write it like that you deserve what you get.
    post edited by LdB_ECM - 2019/09/02 20:56:05
    #15
    ric
    Super Member
    • Total Posts : 23545
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Pointer not initialized (correctly?) 2019/09/02 21:00:38 (permalink)
    0
    A pointer doesn't get "promoted" to an integer.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #16
    NorthGuy
    Super Member
    • Total Posts : 5574
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 21:15:52 (permalink)
    +1 (1)
    The OP's syntax looks valid to me:
     
    "An address constant is a null pointer, a pointer to an lvalue designating an object of static
    storage duration, or a pointer to a function designator; it shall be created explicitly using
    the unary & operator or an integer constant cast to pointer type, or implicitly by the use of
    an expression of array or function type. The array-subscript []and member-access .
    and ->operators, the address & and indirection* unary operators, and pointer casts may
    be used in the creation of an address constant, but the value of an object shall not be
    accessed by use of these operators." (C99 6.6.9)
     
    At any rate, if the compiler doesn't like the expression, it should show an error, not to produce wrong initialization.
    #17
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11285
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/02 23:18:42 (permalink)
    +2 (2)
    The promotion is to an integer AKA it can be negative or not even same range as a pointer and then you add one .

     
    What in the standard makes you believe any sort of "promotion" is happening when adding an integer to a pointer?
    #18
    LdB_ECM
    Senior Member
    • Total Posts : 144
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/03 07:42:06 (permalink)
    -1 (1)
    Seriously basic C .. you can't have it both ways
    oled_buf is an array of OLED_BUF_SIZE + 1 .. right
     
    So this line of code says
    uint8_t *oled_buf_start = oled_buf + 1;

    So consider the right side of that line
    1.) If you claim oled_buf is a pointer then C pointer arithmetic holds and it goes to the byte after the end of the array ... aka some random place. Remember addition on a pointer increments the size of the thing at the pointer.
    2.) It gets promoted to an integer address of oled_buf and one is added
     
    You have to 2 choices .. 1 or 2 ... and both are different degrees of wrong
     
    If you have a different answer explain what you have interpreted "oled_buf" is on the right of that line and that is what I am saying that line is junk it's open to interpretation by the compiler.  Write the line properly in syntax that can not be miss understood.
     
    I should add in C++ it will probably do the right thing because "barren pointers" are more defined but that code is very AC/DC and I know a few C compilers that would do different things with that. If someone has XC8 look at the code and see what it does it is only a couple of lines in a project to check.
    post edited by LdB_ECM - 2019/09/03 08:04:20
    #19
    NorthGuy
    Super Member
    • Total Posts : 5574
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Pointer not initialized (correctly?) 2019/09/03 08:13:58 (permalink)
    +1 (1)
    LdB_ECM
    If you have a different answer explain what you have interpreted "oled_buf" is on the right of that line



    oled_buf is an array. In most contexts (with some exceptions such as sizeof(oled_buf)), it is interpreted as a pointer to the 0-th element of the array. Consequently (oled_buf+1) is the pointer to the 1-st element of the array.
     
    What you suggest - &oled_buf[1] - is for all purposes the same as &*(oled_buf + 1), then removing the redundant "&*", it is (oled_buf + 1), same as OP's.
    #20
    Page: 1234 > Showing page 1 of 4
    Jump to:
    © 2019 APG vNext Commercial Version 4.5