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: Rich Felker <dalias at libc dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 26 Oct 2015 19:49:29 -0400
- 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> <562DDD60 dot 2030803 at redhat dot com> <20151026132507 dot 620af723 dot albert dot aribaud at 3adev dot fr> <562E2B14 dot 3050208 at redhat dot com> <20151026200145 dot GH8645 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1510262232550 dot 7391 at digraph dot polyomino dot org dot uk>
On Mon, Oct 26, 2015 at 10:41:02PM +0000, Joseph Myers wrote:
> On Mon, 26 Oct 2015, Rich Felker wrote:
>
> > I too would strongly prefer NOT repeating the off64_t mistake and
> > instead just having new 32-bit targets with 64-bit time_t. This would
> > also allow fixing lots of old ABI mistakes at the same time.
>
> I don't think there's likely to be any sort of consensus that it was a
> mistake; there's much more likely to be consensus that it was not a
> mistake and that long-term ABI support was and is very helpful to the
> widespread adoption of GNU/Linux (and now the adoption is sufficiently
> widespread that any move to libc.so.7 would likely be very hard, although
> I'd welcome the ability to make such a transition occasionally, and maybe
> it would make sense to maintain a list on the wiki of ABI-incompatible
> changes people think would be desirable in such a transition, ***being
> very careful to distinguish changes that have consensus from changes that
> it's just one person's opinion would be a good idea***).
While _FILE_OFFSET_BITS or _TIME_BITS avoids an ABI transition in
libc, they force an ABI transition for all third-party libraries that
use the types. A library that uses off_t in its API and that's built
with _FILE_OFFSET_BITS=64 is ABI-incompatible with a version of
itself, or an application, built with _FILE_OFFSET_BITS=32. Thankfully
the use of these types in pubic APIs is not extremely widespread
outside libc, but it's still a concern and a possible source of subtle
but nasty breakage.
Perhaps there's some way the ABI-incompatibility could be encoded to
catch and avoid that? I don't see any obvious solution though since
you don't want to penalize (refuse to link) libraries where it doesn't
matter, which are much more common.
Another goal that might make this less distasteful than
_FILE_OFFSET_BITS would be a planned timeline for switching the
default to 64.
Rich