This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Array not initialized



I am using CCS 5.2.0.00069 for the MSP430. I have the statements:

#define DFIFO_SIZE 8 // size of debounce FIFO

static unsigned char timDebounceFIFO[DFIFO_SIZE] = { 0 };

The array is not initialized to zero when I run my program.

What did I miss? Is there a setting in the compiler to force it to initialize arrays?

  • Hello,

    did you try initializing all 8 elements?

    You seem to only initialize one of them ... please keep us informed.

    Best Regards,
    Lisa

  • Are you using COFF or EABI?  In COFF mode, the tools do not automatically zero-initialize uninitialized elements; you need to arrange to do so in the linker command file.  EABI mode would initialize this array to all zeros automatically.

  • I would suggest to the compiler naintainers that if any initializer is supplied, the entire arrgregate should be initialized per Standard C rules.  Otherwise it is simply impractical to write the source code to ensure that large static arrays are zero-filled.  We programmers can accommodate the requirement to specify =0 but not to specify ={0,0,0,0,0,0,0,.../*a zillion of these*/...,0,0,0,0,0,0,0}.

    On many other platforms, initialized modifiable data is put into the .data section and uninitialed data is put into .bss.  Then the run-time start-up module uses linker symbols which specify .bss bounds to zero-fill all of .bss (this works so long as all-0-bits is a valid representation for a null pointer value and for floating-point zero values).  There is no reason I know of that COFF mode couldn't be changed to do this.

    One of the main reasons for using a compiler is to get its help in taking care of such matters, so we don't have to deal with them ourselves.

  • For those reading along, the C standard does require static storage duration objects to be initialized to (essentially) all zeros and NULLs, as well as elements of non-static-storage duration objects with an initializer that doesn't have enough elements.

    Believe me, I'd much rather have the compiler handle this, but (for COFF) the official TI position is that user is responsible for getting this done.  The usual suggestion is to add a fill value to the linker command file.  The argument (not mine) that this is OK is 1) the linker is part of the implementation, therefore the implementation is capable of zero-initialization, and 2) this is a freestanding implementation, so it is not bound by the rule on static storage duration initialization.

    Believe it or not, the lack of initialization is considered desirable in some situations because it leads to shorter boot time.

    In EABI mode, the TMS470, C6000, and MSP430 compilers do perform the initialization.  For EABI, it was recognized that the default mode should be to adhere to the standard without needing to take extra steps; users who desire non-standard behavior will have the responsibility to take extra action.  EABI does in fact do efficient initialization as you describe.  EABI is considered the future for the compiler, and I seriously doubt that any change to the COFF behavior will make it through.

  • I wasn't arguing against not initializing when there is no explicit initializer given in the declaration, because I understand the rationale behind making this exception to standard conformance.  I was arguing that when the user does specify at least one initializer for an aggregate, it would be good for all the other members of the aggregate to get the C standard-specified default initialization.  That would still provide the desired behavior for missing initializer but would give the programmer a convenient, portable way to get full 0 initialization where desired.  There are several possible workarounds, but they're not particularly convenient.

    I understand that EABI is preferred, but since COFF is (still) the default there is a natural tendency to use it.

  • Interesting firestorm created by my assumption. Thanks all. Yes, I was using COFF.

  • Does anybody know if there's a way to disable the automatic array initialization when using EABI? I'm writing a memory test and thought I would simplify the code by using C arrays that I map onto the memory using the linker. However, since I have 128MB of DDR, I discovered it was being zero'ed out as part of the compiler init code which is taking a long time. I would like to diable this but yet stay with EABI in case COFF is depricated for good. If not, I can always go the hardwired address approach, it just makes the code a bit less portable I guess.

    Thanks

  • Brad Caldwell said:

    Does anybody know if there's a way to disable the automatic array initialization when using EABI? I'm writing a memory test and thought I would simplify the code by using C arrays that I map onto the memory using the linker. However, since I have 128MB of DDR, I discovered it was being zero'ed out as part of the compiler init code which is taking a long time. I would like to diable this but yet stay with EABI in case COFF is depricated for good. If not, I can always go the hardwired address approach, it just makes the code a bit less portable I guess.

    The TMS470 ARM C Compiler's User's Guide available on the Processor Wiki site has in Section 6.9.5.1 an indication this can be turned off by using the --zero_init=off compiler flag.