Y2038 and C++ ABIs

Y2038 and C++ ABIs

[Ben Hutchings]

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?

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: Y2038 and C++ ABIs

[Albert ARIBAUD]

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