Re: First draft of the Y2038 design document

[Rich Felker <dalias at libc dot org>]

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