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

From: Paul Eggert <eggert at cs dot ucla dot edu>
To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
Cc: GNU C Library <libc-alpha at sourceware dot org>
Date: Sun, 1 Nov 2015 18:34:10 -0800
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> <5630A213 dot 1070304 at arm dot com>

Szabolcs Nagy wrote:


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.

That's a reasonable caveat. Even there, though, if the glibc manual says thatsetting TZ to ":right/America/Los_Angeles" affects the interpretation of leapseconds (and therefore the behavior of gmtime_r), this would arguably fall underthe umbrella of implementation-defined behavior. At any rate, severalimplementations (not just glibc) have this behavior, and if POSIX were intendedto prohibit it I would expect clearer wording to that effect.

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").

Surely any such data race will exist with localtime_r, too. If there's a bug inthis area a bug report should be filed, and fixing the bug will most likely fixboth localtime_r and gmtime_r.

Follow-Ups:
- Re: First draft of the Y2038 design document
  - From: Zack Weinberg
- Re: First draft of the Y2038 design document
  - From: Rich Felker

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