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: Florian Weimer <fweimer at redhat dot com>
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 26 Oct 2015 16:01:45 -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>
On Mon, Oct 26, 2015 at 02:31:00PM +0100, Florian Weimer wrote:
> On 10/26/2015 01:25 PM, Albert ARIBAUD wrote:
>
> >> On the glibc side, does symbol versioning really buy us that much? It
> >> seems that quite a few libraries (including libstdc++, I think) expose
> >> relevant types in their interfaces, so these interfaces would have to be
> >> versioned as well. I wonder where this would end.
> >
> > So far, I haven't found a need for symbol versioning in Y2038 related
> > changes, since the new syscalls do not need versioning (...yet) and
> > the old ones are one-for-one replacements of existing syscalls none of
> > which needs versioning (I only mentioned symbol versioning because I
> > saw it used in LFS introduction, which I have perused for guidance,
> > and I wanted to make it explicit that I'd considered it).
>
> Ah, sorry, I completely missed that you do not plan to change any
> existing types and (source-level) interface.
>
> This means my concern about versioning is unfounded because you do not
> want to use this mechanism. But I'm not convinced this is the right
> approach. Surely patching existing software to support the new *64
> interfaces is more work than just porting to a new 32-bit target which
> happens to have a 64-bit time_t? I'm worried about the knock-on effects
> these changes have.
>
> Sorry if these trade-offs have already been reviewed.
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.
Also, it seems 32-bit archs will be long-obsolete/gone in all
environments except embedded before we get anywhere near Y2038, so it
probably suffices to focus on archs that are actually relevant to
embedded use -- and it's a lot easier for embedded users to switch to
a new ABI than it is for desktop/enterprise/etc. type distributions.
Are there many 32-bit embedded-relevant archs glibc actually supports
and gets used on other than i386, arm, and maybe mips?
Rich