[quote user="Archaeologist"]
For your example, with C2000 compiler version 5.2.10 using only the --gcc option, the object myArray is direct-initialized, and therefore the compiler writes out zeroes for all of the uninitialized members. If you are using other options, this object might not be direct-initialized; what options are you using? The fact that FLASH memory is involved is irrelevant; the compiler makes the decision, and has no idea what sort of memory is to be used.
I am using the '--gcc' option to enable the use of designated initializers. I'm also using '-ml -mt -g -s -o3' (unified, large memory model, and a few diagnostics options, and optimization). What options would would disable direct-initialization of this object?
Let me confirm I understood correctly:
It sounds like for non-const objects the compiler explicitly create cinit initialization records up to the last exlicitly initialized element in the object, thus no elements after that will explicitly be initialized to zero. These non-const objects may typically reside in RAM, so even though the compiler deviates from the norm here, that might be okay if you remember to initialize all of your RAM to zero, right? This would assume that cinit doesn't write over the initialized RAM values where elements of a sparsely initialized object have not been explicitly initialized by cinit.
Const objects differ in that they use direct initialization and are not initialized in the same way as non-const objects thus this 'truncation' of cinit records after the last explicitly initialized member as described wiki to does not apply to const objects. That means any element in a const object that is not explicitly initialized with a designated initializer will be automatically [directly] initialized to zero, even if designated initializers are used to sparsely initialize the const object. This is the behavior I would expect, and if true, answers the question I originally tried to ask in this thread.