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: Florian Weimer <fweimer at redhat dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 26 Oct 2015 14:31:00 +0100
- 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>
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.
Florian