Re: Y2038 and C++ ABIs

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

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