This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: First draft of the Y2038 design document
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 28 Oct 2015 10:23:15 +0000
- Subject: Re: First draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20151026001252 dot 590e09c1 dot albert dot aribaud at 3adev dot fr> <562EEE05 dot 1080304 at cs dot ucla dot edu> <20151027034324 dot GW8645 at brightrain dot aerifal dot cx> <562F3C6E dot 30905 at cs dot ucla dot edu> <20151027141026 dot GX8645 at brightrain dot aerifal dot cx> <562FE305 dot 7090004 at cs dot ucla dot edu> <20151027205654 dot GY8645 at brightrain dot aerifal dot cx> <562FE594 dot 1050601 at cs dot ucla dot edu> <20151027214243 dot GA8645 at brightrain dot aerifal dot cx> <562FF8AC dot 90206 at cs dot ucla dot edu> <20151027224217 dot GC8645 at brightrain dot aerifal dot cx> <56300020 dot 6090001 at cs dot ucla dot edu>
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.