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: Joseph Myers <joseph at codesourcery dot com>
- 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 13:42:14 +0000
- 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>
On Mon, 26 Oct 2015, Florian Weimer wrote:
> On the glibc side, does symbol versioning really buy us that much? It
What do you mean by symbol versioning here?
If you mean ELF symbol versioning, then obviously every new interface gets
allocated the symbol version for the glibc version in which this support
is added (e.g. GLIBC_2.24 if the support goes into 2.24). That's
completely standard for all glibc API additions - we keep supporting old
binaries while ensuring binaries using new interfaces fail loudly when run
with old glibc.
If you mean the separate versioning system for struct stat referred to on
that wiki page (inlines / libc_nonshared functions calling *xstat*
functions with an explicit version number argument): I suspect this system
is in a sense obsolete given ELF symbol versioning (but predates it) - but
given that this is in use for existing struct stat interfaces, I think it
would be excessively confusing to use it for existing stat interfaces but
not for the corresponding ones using 64-bit time_t.
--
Joseph S. Myers
joseph@codesourcery.com