mbox series

[0/2] Y2038 support batch 1 - __time64_t and __tz_convert

Message ID 20180613070019.4639-1-albert.aribaud@3adev.fr
Headers show
Series Y2038 support batch 1 - __time64_t and __tz_convert | expand

Message

Albert ARIBAUD (3ADEV) June 13, 2018, 7 a.m. UTC
This is the first batch of Y2038 support patches.

The first patch provides __time64_t, the 64-bit counterpart of time_t,
to be used in 64-bit-time implementations of public APIs related to time.

The second makes __tz_convert compatible with 64-bit time. This implies
creating 64-bit-time versions of its callers and turning their original
(32-bit-time) versions into wrappers. 

Albert ARIBAUD (3ADEV) (2):
  Y2038: add type __time64_t
  Y2038: make __tz_convert compatible with 64-bit-time

 bits/typesizes.h                              |  1 +
 include/time.h                                | 29 +++++++++++---
 posix/bits/types.h                            |  3 +-
 sysdeps/mach/hurd/bits/typesizes.h            |  1 +
 .../unix/sysv/linux/alpha/bits/typesizes.h    |  1 +
 .../unix/sysv/linux/generic/bits/typesizes.h  |  1 +
 sysdeps/unix/sysv/linux/s390/bits/typesizes.h |  1 +
 .../unix/sysv/linux/sparc/bits/typesizes.h    |  1 +
 sysdeps/unix/sysv/linux/x86/bits/typesizes.h  |  1 +
 time/Versions                                 |  5 +++
 time/ctime.c                                  | 21 ++++++++--
 time/ctime_r.c                                | 21 ++++++++--
 time/gmtime.c                                 | 38 ++++++++++++++++---
 time/localtime.c                              | 36 ++++++++++++++++--
 time/offtime.c                                | 12 +++---
 time/tzfile.c                                 | 14 ++-----
 time/tzset.c                                  | 30 ++++++---------
 17 files changed, 160 insertions(+), 56 deletions(-)

Comments

Albert ARIBAUD (3ADEV) June 13, 2018, 7:58 a.m. UTC | #1
Added note (will be part of cover letter for all future Y2038 patch
posts):

All Y2038 patches are tested functionally using an ad hoc framework
published at https://github.com/3adev/y2038 which runs tests using times
below, at and beyond the Y2038 limit. The tests are run on ARM
architecture.

These patches have also been tested using build-many-glibcs.py, always
for x86_64, aarch64, arm and powerpc compilers, and regularly for all
compilers, and found to give the same results as those of the current
glibc master above which the patches were created.

On Wed, 13 Jun 2018 09:00:17 +0200, "Albert ARIBAUD (3ADEV)"
<albert.aribaud@3adev.fr> wrote :

> This is the first batch of Y2038 support patches.
> 
> The first patch provides __time64_t, the 64-bit counterpart of time_t,
> to be used in 64-bit-time implementations of public APIs related to time.
> 
> The second makes __tz_convert compatible with 64-bit time. This implies
> creating 64-bit-time versions of its callers and turning their original
> (32-bit-time) versions into wrappers. 
> 
> Albert ARIBAUD (3ADEV) (2):
>   Y2038: add type __time64_t
>   Y2038: make __tz_convert compatible with 64-bit-time
> 
>  bits/typesizes.h                              |  1 +
>  include/time.h                                | 29 +++++++++++---
>  posix/bits/types.h                            |  3 +-
>  sysdeps/mach/hurd/bits/typesizes.h            |  1 +
>  .../unix/sysv/linux/alpha/bits/typesizes.h    |  1 +
>  .../unix/sysv/linux/generic/bits/typesizes.h  |  1 +
>  sysdeps/unix/sysv/linux/s390/bits/typesizes.h |  1 +
>  .../unix/sysv/linux/sparc/bits/typesizes.h    |  1 +
>  sysdeps/unix/sysv/linux/x86/bits/typesizes.h  |  1 +
>  time/Versions                                 |  5 +++
>  time/ctime.c                                  | 21 ++++++++--
>  time/ctime_r.c                                | 21 ++++++++--
>  time/gmtime.c                                 | 38 ++++++++++++++++---
>  time/localtime.c                              | 36 ++++++++++++++++--
>  time/offtime.c                                | 12 +++---
>  time/tzfile.c                                 | 14 ++-----
>  time/tzset.c                                  | 30 ++++++---------
>  17 files changed, 160 insertions(+), 56 deletions(-)
> 



Cordialement,
Albert ARIBAUD
3ADEV
Joseph Myers June 13, 2018, 2:08 p.m. UTC | #2
On Wed, 13 Jun 2018, Albert ARIBAUD wrote:

> These patches have also been tested using build-many-glibcs.py, always
> for x86_64, aarch64, arm and powerpc compilers, and regularly for all
> compilers, and found to give the same results as those of the current
> glibc master above which the patches were created.

Since build-many-glibcs.py should give clean results everywhere except 
i686-gnu, and since this patch adds Versions entries at a public ABI 
version but has no *.abilist updates, I'm skeptical of the above 
description of testing.  You should have no ABI test failures before the 
patch series, anywhere, whether in your normal ARM testing or with 
build-many-glibcs.py, and without *.abilist updates you should be seeing 
such failures after the patch series.

Any patch adding new ABIs at public versions always needs to include the 
ABI baseline updates for *all* glibc configurations.

You should do full execution testing for at least one 64-bit 
configuration, as well.
Albert ARIBAUD (3ADEV) June 13, 2018, 3:38 p.m. UTC | #3
Hi Joseph,

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

> On Wed, 13 Jun 2018, Albert ARIBAUD wrote:
> 
> > These patches have also been tested using build-many-glibcs.py, always
> > for x86_64, aarch64, arm and powerpc compilers, and regularly for all
> > compilers, and found to give the same results as those of the current
> > glibc master above which the patches were created.  
> 
> Since build-many-glibcs.py should give clean results everywhere except 
> i686-gnu, and since this patch adds Versions entries at a public ABI 
> version but has no *.abilist updates, I'm skeptical of the above 
> description of testing.  You should have no ABI test failures before the 
> patch series, anywhere, whether in your normal ARM testing or with 
> build-many-glibcs.py, and without *.abilist updates you should be seeing 
> such failures after the patch series.
>
> Any patch adding new ABIs at public versions always needs to include the 
> ABI baseline updates for *all* glibc configurations.

Right now I only update abilists for ARM and PowerPC as these are
the ones for which I run functional testing. I can update others but I
won't be able to test them functionally.

In any case, I'll group together related changes to Versions and
abilists in the same patch.  

> You should do full execution testing for at least one 64-bit 
> configuration, as well.

My minimal set includes x86_64-linux-gnu, aarch64-linux-gnu,
arm-linux-gnueabi and powerpc-linux-gnu, so this covers two different
64-bit configurations.

(my maximal set is 'all compilers and all glibcs' -- including i686-gnu
for the sake of it -- but as this takes around 30 hours on a reasonably
fast machine, I don't run it for every change.)

Cordialement,
Albert ARIBAUD
3ADEV