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 <m...@squareconnect.com> 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 <goldsi...@gmx.de> 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 <piotr.pi...@embedded-engineering.pl> 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 >>> lwip-users@nongnu.org >>> http://lists.nongnu.org/mailman/listinfo/lwip-users >> >> _______________________________________________ >> lwip-users mailing list >> lwip-users@nongnu.org >> 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 > lwip-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
