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: Rich Felker <dalias at libc dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 27 Oct 2015 18:42:17 -0400
- 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>
On Tue, Oct 27, 2015 at 03:20:28PM -0700, Paul Eggert wrote:
> On 10/27/2015 02:42 PM, Rich Felker wrote:
> >whether a function accesses the environment is a part
> >of its interface contract.
>
> Sure, but part of the POSIX contract is that the application must
> set TZ (if it sets it at all) to a value that POSIX allows. If the
This is only a requirement when executing the standard utilities or
calling functions which depend on TZ.
> application doesn't follow the application's part of contract, the
> implementation need not follow the implementation's part (some of
> which you quoted). If an application messes with PATH, for example,
> it might not get standard behavior. Likewise if it messes with
> LC_ALL, SHELL, ENV, POSIXLY_CORRECT, and so forth. TZ is just
> another variable on this list.
I'm not going to argue over whether this reasoning is correct because
it's aside from the point: it's impossible to implement functions
which are not specified to inspect the environment in a way that
requires inspecting the environment, due to data races. Whether it's
theoretically permitted for an implementation to depend on env
variables in the way you claim, it's technically impossible to produce
such an implementation because the data you want to use could be
clobbered concurrently. There are potential workarounds like backing
up the environment vars you want in libc init code and using these
saved initial values rather than the current value, but that's an
utter mess and highly inconsistent (e.g. if you setenv TZ later to
something without leap seconds, the change will be reflected in
localtime but not gmtime). In any case glibc does not do this but just
gets it wrong on the matter of permitted vs forbidden side efficts.
Rich