This is the mail archive of the
mailing list for the newlib project.
Re: unsetenv() patch for TZ
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Date: Fri, 7 Jun 2013 12:23:08 +0200
- Subject: Re: unsetenv() patch for TZ
- References: <3862C5643B15B6468269546753EB2A92055821DD at BLTSXVS01 dot govsolutions dot com> <20110709121946 dot GM4726 at calimero dot vinschen dot de> <51B1001E dot 9000805 at LGSInnovations dot com>
- Reply-to: newlib at sourceware dot org
On Jun 6 17:33, Craig Howland wrote:
> On 07/09/2011 08:19 AM, Corinna Vinschen wrote:
> >Having said that, shouldn't the tzset() call better be removed in
> >_setenv_r and called in the affected functions?
> It's been a while, but to return to this since I'm running into it
> again and would like to get away from a local workaround:
> Good question. But, no, I suggest that it is better to make the
> addition to unsetenv() rather than to use your suggestion for
> footprint reasons (in addition to my original
> less-likely-to-cause-backwards-compatibility reason).
> If we were to remove tzset() from setenv and add it to ctime(),
> localtime(), mktime(), and strftime(), we would be forcing the
> environment functions to be linked when any of those 4 functions
> were called.
> Having tzset() called by unsetenv() and setenv() can equally be
> claimed to be pulling tzset() in when perhaps it might not be
> wanted, but this seems a more likely case than the former. That is,
> if you are using environment variables, it seems much more likely
> that you'd also be using time functions at the same time than the
> flip case.
I disagree. The fact that some target uses environment functions
is no conclusive reason to believe that the application uses time
functions *and* needs TZ.
> In summary, I think that technically either calling tzset() from the
> related time functions or from the environment functions could work
> properly and be standard-compliant. But I think that the
> environment method better fits newlib's desire for small footprints,
> and suggest that route.
Let's have a look into the footprints of the object files. I took the
two targets I have handy all the time. The size is the combined size
of text, data, rdata and bss segments, in bytes (ctime_r.o and lcltime_r.o
are irrelevant; they just call other functions):
setenv_r.o 844 880
getenv_r.o 288 256
mktime.o 2064 2224
mktm_r.o 1808 2000
strftime.o 8004 8416
tzset_r.o 1388 1600
Tzset alone is bigger than setenv/getenv combined, so by adding a tzset
call you raise the size of an executable using the environment functions
by more than 100%.
On the other hand, if you add tzset to any of the time functions, you
raise the size of the executable by <75% when only using mktime or only
using ctime/localtime, by <40% when using both functions, and by <20%
when using strftime.
So, to me it looks much more reasonable to call tzset from the time
Additionally, if you want to avoid to pull in tzset at all cost, you
can either define your own, empty tzset_r function, or you make the
tzset call in the time functions dependent of a compile time option.