Re: [lwip-devel] [bug #35587] Uninitialized pointer

[David Brown]

On 22/02/2012 09:27, Simon Goldschmidt wrote:
> Update of bug #35587 (project lwip):
>
>                    Status:                    None =>  Invalid
>               Open/Closed:                    Open =>  Closed
>
>      _______________________________________________________
>
> Follow-up Comment #1:
>
> In C, global uninitialized variables (no matter if 'static' or globally
> visible), are implcitly initialized to '0' (or 'NULL' for pointer types). This
> must be done by the startup code before 'main()' is called (e.g., for gcc, the
> section '.bss' is cleared by looping over the whole section and filling it
> with zeros).
>
> This is part of the C standard. If it's not working for you, there's a bug in
> your startup code. This is a common error found in hand-written startup code.
> Some compilers allow skipping the initialization to save space, but that's not
> standard conformant.
>
> Closing as invalid.

Note that despite this being part of the C standards, there are a few 
compiler toolchains that stubbornly refuse to implement it.  TI's Code 
Composer is one of these - it does not zero the statically allocated 
uninitialised data at startup (unless you add your own code to do so). 
It even has a comment in the manual, telling you that this behaviour is 
non-standard!

Obviously such toolchains should be boycotted when possible - there is 
no excuse for this non-standard behaviour as default.  But the 
unfortunate facts of developers' lives is that sometimes these are 
unavoidable - I know I have gone through a lot of hair-pulling as a 
result of Code Composter's non-standard behaviour (though not with lwip 
involved).

Because of the poor quality tools are sometimes used, a lot of highly 
portable code makes a point of explicitly initialising everything to 0. 
 It has the disadvantage of using more space and more time at startup 
(it is more efficient to zero out a whole block, than copy zeros as part 
of the initialised data setup).  And it only makes sense if it is done 
consistently across the project - there is no point in making timers.c 
safe for bad toolchains if there are other modules that rely on standard 
C initialisation code.  But it is perhaps something to consider.

mvh.,

David