[PATCH] tzset_internal: do not reset old_tz if no change from default value

[Dominique Martinet]

Thanks for the reply,

Paul Eggert wrote on Thu, Feb 27, 2025 at 04:26:25PM -0800:
> On 2/27/25 13:53, Dominique Martinet wrote:
> > - the `TZ` env var could point to a symlink just the same
>
> Read glibc/time/tzset.c's tzset_internal function to see more details than
> what I've just said. This behavior isn't documented anywhere, and it'd be
> unwise to rely on it in future glibc versions.

Right, this is the function I patched :)

I'm was just pointing out that it's weird that setting the env var gets
a special treatment of "the timezone will never change", for example
that means that if you upgrade your tzdata then programs picking up the
tz from the default /etc/localtime would see that update immediately but
programs using the same tz as set by localtime (which didn't change)
would not see it.

That behaviour seems to date from 1996 and I'm not arguing to change
this now, but I got a one line reply which didn't make sense to me.

> > - even if it is a symlink
> 
> It does not matter whether the files are symbolic or hard links. What
> matters are their contents when you open and read them.

Yes, that doesn't change my point either, which was I don't see what's
so great about having TZ set to make the function thread safe or not.

Anyway, it turns out that the patch is moot anyway because __tzset()
does take a lock, so it really was safe all along and can't be what
cause the crash I was looking at.
It just happens that my crash is hard enough to reproduce that removing
this influx of constant free/mallocs made it just hard enough to
reproduce that I couldn't see it anymore... So I'm back to square one
and I won't push this thread further.

(I was led to think this could be a culprit because of TSan, which does
not recognize __libc_lock_lock and reported this as a race, even if it
is not one)


Thank you for the quick replies regardless,
-- 
Dominique Martinet | Asmadeus