This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libc/time/gmtime_r.c, libc/time/lcltime_r.c,, libc/time/local.h, libc/time/mktm_r.c: move localtime related functionality, from _mktm_r() to new _mklocaltm_r() to break dependency of gmtime() on, timezones



On September 4, 2014 7:30:30 AM CDT, Corinna Vinschen <vinschen@redhat.com> wrote:
>On Sep  4 14:18, Freddie Chopin wrote:
>> W dniu 2014-09-04 13:59, Corinna Vinschen pisze:
>> >In this scenario, since _gmtime_r will be included
>> >as soon as localtime_r is used, the arrays would just go into the
>> >_gmtime_r source file as well.
>> 
>> Well, it's probably not that easy. There's also __tzcalc_limits(),
>which
>> also uses this array. This function is used by mktime(), _tzset_r()
>and -
>> indirectly - by localtime(). That's why I think it would be
>reasonable to
>> move this array to separate file - when you use mktime(), you don't
>need
>> gmtime().
>
>Indeed.
>
>> The other option is to define the contents of this array as
>> #define macro in local.h and just have the array in two files, but
>that's
>> not very elegant...
>
>It's probably also not a good idea space-wise.

FWIW RTEMS has a test which has three tasks printing the time of day. Using gmtime or a friend to split the time into components to print is a sizeable chunk of the binary. 

No surprise that printf is also a large chunk. 

I can gather current size data for this test if you all think having it before and after is good.

--joel

>
>Corinna


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]