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: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 27 Oct 2015 15:20:28 -0700
- 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>
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 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.
POSIX places constraints on what applications can do with the
environment, and applications that violate these constraints do so at
their peril. Glibc does not go out of its way to break nonconforming
applications, but it can and does give nonconforming applications some
useful behavior that would otherwise violate POSIX.