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

[Pettinato, Jim]

Another comment: Many 'C' toolchains simply just zero all of the target
RAM before the explicit initialization step is executed. Hence, any
static vars not explicitly initialized are automatically zero (unless
you have a very weird target that does not use zero as a NULL pointer).


> 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.



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users