[Bug time/22639] year 2039 bug for localtime etc. on 64-bit platforms

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22639

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  78274dc8ceb21bb7efd8baef29e1f00031b9c1c6 (commit)
      from  6f7fdeeb69776d0d2f67fb26f92ad2807445ca5e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=78274dc8ceb21bb7efd8baef29e1f00031b9c1c6

commit 78274dc8ceb21bb7efd8baef29e1f00031b9c1c6
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Fri May 18 11:57:15 2018 +0000

    Fix year 2039 bug for localtime with 64-bit time_t (bug 22639).

    Bug 22639 reports localtime failing to handle time offset transitions
    correctly in 2039 and later on platforms with 64-bit time_t.

    The problem is the use of SECSPERDAY (constant 86400) in calculations
    such as

        t = ((year - 1970) * 365
         + /* Compute the number of leapdays between 1970 and YEAR
              (exclusive).  There is a leapday every 4th year ...  */
         + ((year - 1) / 4 - 1970 / 4)
         /* ... except every 100th year ... */
         - ((year - 1) / 100 - 1970 / 100)
         /* ... but still every 400th year.  */
         + ((year - 1) / 400 - 1970 / 400)) * SECSPERDAY;

    where t is of type time_t and year is of type int.  Before my commit
    92bd70fb85bce57ac47ba5d8af008736832c955a (an update from tzcode,
    included in 2.26 and later releases), SECSPERDAY was obtained from a
    file imported from tzcode, where the value included a cast to
    int_fast32_t.  On 64-bit platforms, glibc defines int_fast32_t to be
    long int, so 64-bit, but my patch resulted in it changing to int.
    (The bug would probably have existed even before my patch for x32,
    which has 64-bit time_t but 32-bit int_fast32_t, but I haven't
    verified that.)

    This patch fixes the problem by including a cast to time_t in the
    definition of SECSPERDAY.  (64-bit time support for 32-bit systems
    should move such code that isn't a public interface to using the
    internal 64-bit version of time_t throughout.)

    Tested for x86_64 and x86.

        [BZ #22639]
        * time/tzset.c (SECSPERDAY): Cast to time_t.
        * time/tst-y2039.c: New file.
        * time/Makefile (tests): Add tst-y2039.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                            |    7 +++++++
 time/Makefile                        |    2 +-
 elf/tst-debug1.c => time/tst-y2039.c |   24 ++++++++++++++++++------
 time/tzset.c                         |    2 +-
 4 files changed, 27 insertions(+), 8 deletions(-)
 copy elf/tst-debug1.c => time/tst-y2039.c (59%)

-- 
You are receiving this mail because:
You are on the CC list for the bug.