Re: [PATCH 1/2] Y2038: add type __time64_t

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

Hi Joseph,

On Wed, 13 Jun 2018 14:13:00 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> There is a key definition you are missing in this patch: one that says 
> whether the particular glibc configuration supports 32-bit time_t at all.
> 
> This new macro could go in bits/wordsize.h, or in its own installed 
> header.  The value is normally the same as (__WORDSIZE == 32), *except* on 
> x32, which already has 64-bit time_t despite 32-bit wordsize.
> 
> The new macro would be used, in the installed headers, to control whether 
> an explicit _TIME_BITS=32 is valid or not.  It would also be used, in 
> glibc internals, to control whether there are separate 32-bit interfaces 
> that wrap 64-bit ones, or whether the 64-bit names are just #defined to 
> the generic ones (#define __clock_gettime64 __clock_gettime, in some 
> internal header, for example) to avoid creating any new interfaces in the 
> case where time_t is already 64-bit, while avoiding the need for lots of 
> conditionals where glibc-internal code written for 64-bit time_t wishes to 
> call such interfaces.

Which would be best:

- a "boolean" macro (e.g. __TIMESIZE32) defined as (__WORDSIZE == 32)
  except for x32 where it would be defined as 1, or

- a "size" macro (e.g. __TIMESIZE) defined equal to __WORDSIZE except
  for x32 where it would be defined as 64?

I have a slight preference for the "size" form.

Cordialement,
Albert ARIBAUD
3ADEV