Re: [lwip-users] Initialization of global variables

[mat henshall]

Jeff, that is a good solution. Next time I need to do this, I will
look into that.

Thanks.

M
On Fri, Nov 5, 2010 at 2:00 PM, Jeff Barber <address@hidden> wrote:
> Why don't you just imitate what the boot loader would do?  Find the
> symbol that indicates the beginning of BSS and the symbol that
> indicates the end, find the difference and clear.  Then only do that
> when your wakeup has decided there's something to do. Linker-dependent
> but usually these symbols are accessible or can be made so.
>
> Jeff
>
> On Fri, Nov 5, 2010 at 4:51 PM, mat henshall <address@hidden> wrote:
>> Simon...
>>
>> It sounds like you are  frustrated that this issue has been raised
>> multiple times and doesn't seem to go away! I am sorry to add to the
>> 'fire'. In all the important things that could be done/worked on this
>> is, I am sure a low priority.
>>
>> I wanted to bring to your attention a use case where it makes sense to
>> turn off compliance with the standard (I believe most compliers allow
>> this) ... and I pass on the reasoning from the engineers who made the
>> choice... The circumstance they are concerned about is when a very low
>> power device wakes up and decides to do nothing.... then not reading,
>> not writing not zeroing... dong as little as possible can make a big
>> differnece to battery life. Ofcourse, if you need to wake up and get
>> on the netowork, all bets are off, and the time taken to zero out is
>> irrrelevant. But as the ratio of wake up and do nothing to wake up and
>> talk to the radio is often 100000 to 1 or more, it kind of makes
>> sense. I believe they measured it.
>>
>> I have had this discussion with other library writers... and you are
>> correct, Ansi C says it should be zero'd... doesn't stop me from
>> having to search through the libraries every time there is a version
>> increment to see if I need to manually init to zero in these
>> applications.
>>
>> A single function where all the global variables are gathered together
>> and zero'd out that can optionally be linked in makes a cleaner
>> interface for this odd, but not unknown usecase.
>>
>> Regards,
>>
>> mat
>>
>> On Fri, Nov 5, 2010 at 12:44 PM, Simon Goldschmidt <address@hidden> wrote:
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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