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


On Sun, Nov 1, 2015 at 9:34 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> Szabolcs Nagy wrote:
>> 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
> in this area a bug report should be filed, and fixing the bug will most
> likely fix both localtime_r and gmtime_r.

I believe Rich has been trying to say that this data race is
_unfixable_, because applications are permitted to modify the data
pointed-to by `environ` directly, in-place, and without taking any
locks.  Thus, any library function that inspects the environment is
potentially exposed to data races against modifications by another
thread, and the best we (implementors) can do is document which C
library functions examine the environment.

I do not have an informed opinion on whether POSIX defines the set of
functions that are allowed to examine the environment.

zw


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