This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: First draft of the Y2038 design document


On 27/10/15 22:52, Paul Eggert wrote:
On 10/27/2015 03:42 PM, Rich Felker wrote:
This is only a requirement when executing the standard utilities or
calling functions which depend on TZ.

No, it's a requirement that conforming applications cannot set TZ to a value like "right/America/Los_Angeles",
at all times. This is not a requirement that a conforming application can blithely ignore merely because it's
currently executing certain functions. This is clearly stated in the environment-variable section.


That argument does not work if TZ is set to
":right/America/Los_Angeles", which a conforming
application may do.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

In any case glibc does not do this but just
gets it wrong on the matter of permitted vs forbidden side efficts.

This seems to be veering into a different area, where perhaps there is a glibc bug (presumably which can be
illustrated by using only POSIX-specified TZ values), but that's a different matter.


if one thread changes TZ=GMT0 to TZ=GMT-1 while
another concurrently calls gmtime_r, then glibc
introduces a data race when it calls getenv("TZ").

i don't think this is a different matter: gmtime_r
is not allowed to inspect TZ or introduce races
otherwise.


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