lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Brown
Subject: Re: [lwip-devel] [bug #35587] Uninitialized pointer
Date: Wed, 22 Feb 2012 11:23:52 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]