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
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.
mat henshall <address@hidden
Simon,I have hit this problem where an environment by default turns off theinitialization of globals for 'efficiency' and expects an applicationto explicit zero out the globals and statics as needed. For example, Iuse an ultra low powered wifi chip that has lwIP in ROM and it loadsapplicaiton code from flash on 'wake up'. TIme is energy, so the lesstime the chip takes to wake up and see if it really needs to dosomething and the if not, fall asleep again, the better. Only if youreally want to do something might you want to then initialize thevarious modules etc.When using subsystems and third party libraries, it is always alittle error prone and painful to collect all the various globals intoa 'init_to_zero' function. It would be more pleasant and robust tohave the optional function provided by the library.MatOn Fri, Nov 5, 2010 at 11:53 AM, Simon Goldschmidt <address@hidden> wrote:
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).
Piotr Piwko <address@hidden> wrote:
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:
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;
struct udp_pcb *udp_pcbs;
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!
lwip-users mailing list
lwip-users mailing list
-- Mat HenshallFounder and CEO, Square Connect, Inc.San Jose, CAwww.squareconnect.comcell: 650.814.7585_______________________________________________lwip-users mailing listaddress@hiddenhttp://lists.nongnu.org/mailman/listinfo/lwip-users