This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Y2038 and C++ ABIs
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Ben Hutchings <ben dot hutchings at codethink dot co dot uk>
- Cc: glibc development <libc-alpha at sourceware dot org>
- Date: Sun, 19 Nov 2017 17:00:32 +0100
- Subject: Re: Y2038 and C++ ABIs
- Authentication-results: sourceware.org; auth=none
- References: <1510079492.2465.41.camel@codethink.co.uk>
Hi Ben,
On Tue, 07 Nov 2017 18:31:32 +0000, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote :
> Albert, I reviewed the draft at
> <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign> and I see a
> potential problem with the proposed type changes.
>
> Suppose a C++ library has some function parameters whose types are
> based on struct timespec or struct timeval. Those structure names will
> be mangled into the function symbol names.
>
> If the library is rebuilt on a 32-bit architecture with the updated
> glibc, and it opts in to 64-bit time support, the symbol names change -
> and that's good because the function's ABI really is changing.
>
> However, if it's rebuilt and continues to use 32-bit time, it looks
> like the symbol names might still change because struct timespec would
> be an alias for struct timespec32. That would be very undesirable.
> However, I'm not sure how you intended the type aliasing to be done.
> Would struct timespec be a structure with identical layout to
> timespec32/64 (which avoids this problem), or aliased through a #define
> or some other means?
Thanks Ben for raising this, and sorry for the delay in answering.
The objective is of course to be 100% compatible with existing
source code, i.e. source code which did not specify _TIME_BITS=64
should compile exactly the same with or without the Y2038-proof GLIBC
patches.
IOW, and barring a mistake of mine, the API side of GLIBC should not be
affected at all when 64-bit-time support is added but not selected, and
any source name mangling should also be unaffected.
On the implementation side, there are explicit 32-bit- and 64-bit-time
variants of the various time-related structures since we may need both,
and the 32-bit variants are (intended to be) identical to the public
but should not affect the public API mangling.
Or am I missing the point?
> Ben.
Cordialement,
Albert ARIBAUD
3ADEV