unsetenv() patch for TZ

[Corinna Vinschen]

Hi Craig,

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?
> >
> Corinna:
> 
> 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):

		 i686    x86_64

  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
functions.

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat