Re: [lwip-users] About global parameter initial problem

[David Empson]

----- Original Message ----- 
From: <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Thursday, November 27, 2008 5:04 AM
Subject: Re: [lwip-users] About global parameter initial problem


> bonny gijzen wrote:
> > Wouldn't the code be better if the variables were initialised in the 
> > routines itself?
> > I think a fancy C compiler will optimize it away ...
> Hehe, that's exactly the discussion we had some while ago. The baseline 
> was that we want to leave out unnecessary code to help people with 
> compilers that aren't good in optimizing. Since there are so many 
> different compilers for embedded systems, it's not clear if all are good 
> optimizers...
>
> As to the init code: Sorry, I should have known that since I wrote the 
> init code myself on our platform. Yes, it's not the compiler then. But it 
> _could_ be that the compiler puts the variables into the wrong section 
> where they don't get initialized? And finally, if the init code is not 
> self-written, it should take care of this, shouldn't it?

Indeed. Original ANSI C 1990 standard, section 5.1.2 Execution Environments:

"Two execution environments are defined: freestanding and hosted. In both 
cases, program startup occurs when a designated C function is called by the 
execution environment. All objects in static storage shall be initialized 
(set to their initial values) before program startup. The manner and timing 
of such initialization are otherwise unspecified."

Section 6.5.7 Initialization:

"... If an object that has automatic storage duration is not initialized 
explicitly, its value is indeterminate. If an object that has static storage 
duration is not initialized explictly, it is initialized implicitly as if 
every member that has arithmetic type were assigned 0 and every member that 
has pointer type were assigned a null pointer constant. ..."


Further comments from me:

Variables declared outside functions are by definition static. The above 
rules require that all static variables be set to their initial values 
before the first C function in the application is called, and the initial 
value is defined to be zero for all static variables which don't have an 
explicit initializer.

Compiler-supplied startup code must clear all "uninitialized" static 
variables, or the compiler is not compliant with the ANSI C standard.

User-supplied startup code must do the same, unless the user is willing to 
violate the ANSI C standard in this area and deal with the consequences in 
any code they didn't write themselves.

I think it is perfectly reasonable for LWIP to expect ANSI C compliance in 
this area, and the standard distribution of LWIP should not have explicit 
assignment to zero on static variables.

A good reason for not doing it this way: in an embedded system, the initial 
values for initialized variables are typically loaded into a section in ROM 
and copied to RAM by the startup code. Many embedded compilers will ignore 
the fact that the initializer is zero, resulting in a lot more ROM space 
being taken up by initialized variable values. Explicitly initializing 
variables to zero will therefore waste ROM space, which is often at a 
premium in smaller systems.