lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Initialization of global variables


From: Simon Goldschmidt
Subject: Re: [lwip-users] Initialization of global variables
Date: Fri, 5 Nov 2010 20:44:09 +0100

Excerpt from the ANSI-C Standard (e.g. http://flash-gordon.me.uk/ansi.c.txt):
 If an object that has static storage duration is not initialized
explicitly, 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.  If an object that has
automatic storage duration is not initialized explicitly, its value is
indeterminate./65/
As you can see, there's absolutely no portability issue here! Also, there's no performance gain in not zeroing the variables at startup: when they are explicitly initialized by the application, the loader has to load their initial values from flash/ROM to RAM. When relying on zeroing by the loader, you only have to write zeros starting from a defined point, for a defined length. What's faster now, reading AND writing or only writing?

Also, if you write an ANSI-C compatible loader/startup code, there's no need to manually collect global variables and initialize them with your own C code. also, static globals can't be collected that way as you can't access them from another file.

Finally, we've been having his discussion over and over again, and the ANSI C standard didn't change over the years in that regard. I'm still open for really pressing issues regarding portability, but up to now, I (and other lwIP developers, I guess) haven't been convinced this is such an issue. 

Simon
 

 mat henshall <address@hidden> wrote:

Simon,

I have hit this problem where an environment by default turns off the
initialization of globals for 'efficiency' and expects an application
to explicit zero out the globals and statics as needed. For example, I
use an ultra low powered wifi chip that has lwIP in ROM and it loads
applicaiton code from flash on 'wake up'. TIme is energy, so the less
time the chip takes to wake up and see if it really needs to do
something and the if not, fall asleep again, the better. Only if you
really want to do something might you want to then initialize the
various modules etc.

When using subsystems and third party libraries,  it is always a
little error prone and painful to collect all the various globals into
a 'init_to_zero' function. It would be more pleasant and robust to
have the optional function provided by the library.

Mat

On Fri, Nov 5, 2010 at 11:53 AM, Simon Goldschmidt <address@hidden> wrote:
Hey Piotr,

I hate to turn you down on that, but the variables are deliberately not being initialized: when not initialized (and thus implicitly zeroed at startup), they are put into the uninitialized section and no space on disk/in flash is needed. However when they are initialized to NULL, they are put NGO the initialized data section, which is present on disk/in flash, too.

As to the portability: the C standard requires non initialized data to be initialized to zero at startup. It is a common error in self-made ports to leave out the zeroing of the uninitialized data section (.bss for gnu bcc).

Simon

 Piotr Piwko <address@hidden> wrote:

Hello,

I currently implement the LwIP stack under u-boot environment and I
have one notice regarding global variables initialization. I think
that every global variable which are not static should be initialized
by NULL or 0 value. I mean for example:

file tcp.c:
struct tcp_pcb *tcp_bound_pcbs;
union tcp_listen_pcbs_t tcp_listen_pcbs;
struct tcp_pcb *tcp_active_pcbs;
struct tcp_pcb *tcp_tw_pcbs;

file udp.c:
struct udp_pcb *udp_pcbs;

file netif.c:
struct netif *netif_list;
struct netif *netif_default;

If I leave they uninitialized, after compilation and link operation
they will contain random values which causes the system crash during
LwIP initialized functions. Assumption that they will be automatically
filled by 0 is wrong and non-portable.

This modification can really save a lot of time during integration :)

Anyway I am impressed with LwIP project. It is very useful part of
software. Good job guys!

Regards,

--
Piotr Piwko
http://www.embedded-engineering.pl/

_______________________________________________
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




--

Mat Henshall
Founder and CEO, Square Connect, Inc.
San Jose, CA
www.squareconnect.com
cell: 650.814.7585

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

reply via email to

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