This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is Y2038-proofing in a glibc roadmap somewhere?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, <libc-alpha at sourceware dot org>
- Date: Mon, 3 Aug 2015 17:15:29 +0000
- Subject: Re: Is Y2038-proofing in a glibc roadmap somewhere?
- Authentication-results: sourceware.org; auth=none
- References: <20150618150835 dot 315775b7 dot albert dot aribaud at 3adev dot fr> <20150618132533 dot GG22285 at port70 dot net> <20150618154948 dot 714738c2 dot albert dot aribaud at 3adev dot fr> <20150709100932 dot 3dd2cbf7 dot albert dot aribaud at 3adev dot fr> <alpine dot DEB dot 2 dot 10 dot 1507221418360 dot 21570 at digraph dot polyomino dot org dot uk> <20150803104325 dot 2ec7b9ea dot albert dot aribaud at 3adev dot fr> <CAKCAbMgABZf4bU0FNu1-9bJtM3aS6mPxiZH+J5yk-EsBPReWiA at mail dot gmail dot com>
On Mon, 3 Aug 2015, Zack Weinberg wrote:
> > Hmm, why the relationship with _FILE_OFFSET_BITS? At least at first
> > sight, supporting 64-bit time seems pretty unrelated/orthogonal to
> > supporting 64-bit file sizes.
>
> I don't know for certain what Joseph had in mind, but I believe that's
> just to cut down on the number of combinations the header files need
> to support. 'struct stat', for instance, contains both time_t and
And the number of ABI variants / function exports in the libraries.
One thing to consider in the design is whether you have separate functions
exported from the shared libraries at all for those cases where time_t is
already 64-bit. _FILE_OFFSET_BITS=64 does have separate exports (and
public API names such as stat64 for use with _LARGEFILE64_SOURCE; I don't
see any clear need for API names like that for time_t); avoiding them for
time_t would complicate the headers but simplify the ABI.
Issues with _FILE_OFFSET_BITS=64 that you should definitely seek to avoid
for _TIME_BITS=64 include: (a) stat and stat64 having different layouts on
at least one 64-bit platform (MIPS n64) (that is, whatever _TIME_BITS=64
does on systems where time_t is already 64-bit, it should not change the
layout of any structures); (b) link-time namespace violations (bug 14106);
(c) _FILE_OFFSET_BITS=64 affecting the C++ ABI even when the layout of the
types would otherwise be the same (bug 15766).
The evidence is that libraries affected by the _FILE_OFFSET_BITS value are
more likely nowadays to be built with _FILE_OFFSET_BITS=64 than
_FILE_OFFSET_BITS=32 on GNU/Linux distributions.
--
Joseph S. Myers
joseph@codesourcery.com