This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 22 Feb 2017 11:15:57 -0800
- Subject: Re: Fifth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20170222090511.48be22ed.albert.aribaud@3adev.fr>
One other question: how set-in-stone is this business about _TIME_BITS
defaulting to 32-bit time_t?
I'm asking because the applications I help maintain (coreutils, grep,
Emacs, etc.) don't want to use "backward-compatibility mode". That is,
I'd prefer a default where the implementation defaults to 64-bit time_t
if I don't do anything special. (If I really want 32-bit time_t, which I
don't, I can compile with -D_TIME_BITS=32.)
I wish _FILE_OFFSET_BITS worked this way; it would have saved me hassle
back in the day. Is there some reason we can't do better this time
around, and have _TIME_BITS default to 64?