Re: [v13 2/2] Y2038: make __tz_convert compatible with 64-bit-time

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

Hi Joseph,

Le Wed, 24 Oct 2018 16:14:54 +0000, Joseph Myers
<joseph@codesourcery.com> a écrit :

> Does anyone see a way to make the code dealing with defining wrappers on 
> systems with 32-bit time_t, and using #define to avoid the need for such 
> wrappers on systems where time_t is only ever 64-bit, less repetitive?  My 
> guess is that's hard to do on two counts: (a) because across all the 
> functions in glibc that involve time, there are many differences of detail 
> in the wrappers needed; and (b) because the header code, although more 
> repetitive, involves #define so can't simply be generated from the 
> expansion of some wrapper-generating macro.  ((b) is similar to various 
> questions arising from ideas about symbol namespace that might involve 
> many more such repetitive declarations in installed headers, depending on 
> whether we eliminate any support for compilers without asm redirection 
> support using installed glibc headers.)

I too have noticed how repetitive this is, but I can't see any way to
simplify this code apart from running it through some preprocessor
(other than the cpp it will run through as part of compilation, that
is), and that seems overkill to me.

> In any case, this patch does two different things: it changes certain 
> *internal* interfaces to use 64-bit time (and also to use time values 
> passed directly rather than via pointers), and it sets up versions of 
> *public* interfaces that use 64-bit time.  I'd rather keep the two 
> separate, doing the internal change first (since the internal functions in 
> question don't appear to call any of the public interfaces, only the other 
> way round).  The internal change should be uncontroversial; the change to 
> public interfaces at least could do with more people looking carefully at 
> the design, as we're going to get many more such wrappers and so want to 
> make sure the design is the best we can come up with before adding lots of 
> repetitive code.

I'm fine with splitting the patch, keeping the internal changes here and
moving the public interface changes further down the series.

Cordialement,
Albert ARIBAUD
3ADEV