[Bug libc/12401] New: [PATCH] fix assertion in mktime.c

[Bug libc/12401] New: [PATCH] fix assertion in mktime.c

[rmh at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12401

           Summary: [PATCH] fix assertion in mktime.c
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: rmh@gnu.org


Created attachment 5195
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5195
patch 1

The following assertion in mktime.c:

   verify (long_int_year_and_yday_are_wide_enough,
          INT_MAX <= LONG_MAX / 2 || TIME_T_MAX <= UINT_MAX);

is not satisfiable on any ILP32 architecture with 64-bit time_t.

I propose the following patch to fix the problem.  Given the purpose of this
assertion, I've split my patch in 3 to prove that it doesn't introduce any
regression.  Here's my semi-formal proof:

First let A be (INT_MAX <= LONG_MAX / 2).

  - Patch #1: This works on the assumption that for any value of LONG_MAX, the
whole function either works correctly or fails to compile. With my patch, if a
certain condition A is met, every instance of `long' type is replaced with
`time_t', and the assertion that checks for LONG_MAX now checks for TIME_T_MAX
in its place. It must remain true that for any value of TIME_T_MAX, the whole
function either works correctly or fails to compile, regardless of condition A.

  - Patch #2: If condition A is met, clearly the assertion will always suceed,
so it can be removed.

  - Patch #3: If condition A is met, the second assertion is skipped, which is
equivalent to making A one of its options.

(or in plain English, if longs are too short, time_ts can be used instead)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12401] [PATCH] fix assertion in mktime.c

[rmh at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12401

--- Comment #1 from Robert Millan <rmh at gnu dot org> 2011-01-15 11:43:29 UTC ---
Created attachment 5196
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5196
patch 2

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12401] [PATCH] fix assertion in mktime.c

[rmh at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12401

--- Comment #2 from Robert Millan <rmh at gnu dot org> 2011-01-15 11:43:46 UTC ---
Created attachment 5197
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5197
patch 3

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12401] [PATCH] fix assertion in mktime.c

[rmh at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12401

--- Comment #3 from Robert Millan <rmh at gnu dot org> 2011-01-15 11:47:27 UTC ---
I forgot something regarding patch #1.  If the assert is going to pass with its
left part, then condition A is met, and as a result long is used and its left
part remains unmodified by my patch.  If the assert is going to pass with its
right part, or not pass at all, then my change is not relevant.  So in either
case, no regression is introduced.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12401] [PATCH] fix assertion in mktime.c

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12401

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #4 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-01-15 16:13:16 UTC ---
There are no ILP32 machine supported.  Why should anything be done?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12401] [PATCH] fix assertion in mktime.c

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
         Resolution|WONTFIX                     |FIXED
              Flags|                            |security-

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
This should have been fixed in glibc 2.16 as part of the x32 port.

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