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

[Pettinato, Jim]

I believe your recollection is accurate Bill, but there exists
(existed?) machines that do not use 0 as the internal maching
representation of a NULL pointer. All that the standard says is that if
you convert a NULL pointer to an arithmetic value in your code, the
compiler must generate the answer zero, and vice versa. It does not mean
that what is stored in memory to represent a NULL pointer has to be
zero.

See http://c-faq.com/null/index.html from comp.lang.c for more... And
sorry to be pedantic ;)

__
 
James M. Pettinato, Jr.
Software Engineer
E: address@hidden | P: 814 898 5250 

FMC Technologies Measurement Solutions Inc.
1602 Wagner Avenue | Erie PA | 16510 USA 
Phone: 814 898 5000 | Fax: 814 899-3414
www.fmctechnologies.com 

 

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of bill
Sent: Monday, December 01, 2008 9:56 AM
To: 'Mailing list for lwIP users'
Subject: RE: [lwip-users] About global parameter initial problem

I know I'm a bit late adding to this thread.  Good post David.

One point just to be sure it's understood is that your use of the term
static below doesn't mean variables declared with the static qualifier,
but any non-local variable - both globals and those declared static.

One point on Jim's comment: "unless you have a very weird target that
does not use zero as a NULL pointer".  I seem to recall the ANSI/ISO C
Standard includes a requirement that NULL pointers are 0 in arithmetic
value.  It's not handy to look up but I will check tonight.

There is a lot of existing code written with 'if (ptr) ...' instead of
'if (ptr != NULL) ... which makes the requirement justified.

Bill

> 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



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