Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000469 [1003.1(2008)/Issue 7] System Interfaces Editorial Error 2011-06-30 15:49 2020-03-05 15:07
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Eric Blake
Organization Red Hat
User Reference ebb.asctime
Section asctime
Page Number 590
Line Number 20346
Interp Status Approved
Final Accepted Text See Note: 0000934
Summary 0000469: asctime and integer overflow
Description asctime is undefined if it encounters INT_MAX overflow on tm_year, but
the text describing that uses the wrong offset.
Desired Action At line 20346, change "if timeptr−>tm_year exceeds {INT_MAX}−1990,"
to "if timeptr−>tm_year exceeds {INT_MAX}−1900,"
Tags c99, issue8
Attached Files

- Relationships

-  Notes
(0000874)
eblake (manager)
2011-06-30 16:47

 Like most time-related issues, this one is trickier than expected by
first impressions.

Note that the C99 algorithm specifies a particular output for tm_year
less than -1899, but strftime( ) leaves the output for such years as
undefined (line 63789 documents the issue: Julian and Gregorian
calendars lack year 0, but not all implementations of strftime( )
skip 0). But it seems odd to mandate an implementation of asctime
that cannot be represented in terms of strftime( ).

Furthermore, since the standard is already clear that with asctime( ),
any time that would produce a string with more than 26 bytes has
undefined behavior, it may be smarter to mention that tm_year larger
than 8099 gives undefined results (that is, there is no defined way
to use tm_year in the range between 8100 and {INT_MAX}-1900, since
the documented algorithm on values in that range will produce more
than the documented limit on output bytes).
(0000875)
eblake (manager)
2011-06-30 17:02

 For that matter, ctime( ) makes a non-normative claim that it is
undefined on years before the epoch (line 24106), although I can find
nothing in normative text that supports this claim; that is an even
smaller range, as it would disallow tm_year smaller than 70, rather
than just smaller than -1899.
(0000920)
eblake (manager)
2011-08-04 16:27

 C1x added this restriction, with an even narrower range for valid years:

Likewise, if the calculated year exceeds four digits or is less than the
year 1000, the behavior is undefined.
(0000921)
nick (manager)
2011-08-04 16:35

 Looks like C1X has better words.

Replace the entire paragraph 20345-20348 with:

If any of the members of the broken-down time contain values that are outside their normal ranges (see <xref to time.h>), the behavior of the asctime function is undefined. Likewise, if the calculated year exceeds four digits or is less than the year 1000, the behavior is undefined.
(0000922)
eblake (manager)
2011-08-04 16:52

 Regarding Note: 0000875, ctime() really does have a narrower range than
asctime(), since ctime() is defined in terms of localtime() on a time_t;
and where C99 leaves time_t as an unspecified format, POSIX documents
it as seconds since the Epoch. XBD 4.15 is clear that time_t is thus
undefined prior to the Epoch. That is, there is nothing wrong with
struct tm holding a larger range of valid years than time_t, and
asctime() can process this larger range (down to the year 1000) even
though ctime() can only get down to the year 1970, all while still
complying with the C99 requirements.
(0000934)
msbrown (manager)
2011-08-11 15:22

 The standard states the offset that must be used , and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
The year 1990 in the original text was clearly wrong. We are adopting wording from the C1X draft which covers the desired action.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
If approved, please perform the actions in Note: 0000921 .
(0000935)
msbrown (manager)
2011-08-11 15:23

 We need to verify that C1X doesn't change the wording before it is adopted.
(0001302)
ajosey (manager)
2012-06-29 16:19

 Interpretation proposed 29 June 2012 for final 45 day review
(0001343)
ajosey (manager)
2012-08-30 09:11

 Interpretation approved 30 Aug 2012

- Issue History
Date Modified Username Field Change
2011-06-30 15:49 eblake New Issue
2011-06-30 15:49 eblake Status New => Under Review
2011-06-30 15:49 eblake Assigned To => ajosey
2011-06-30 15:49 eblake Name => Eric Blake
2011-06-30 15:49 eblake Organization => Red Hat
2011-06-30 15:49 eblake User Reference => ebb.asctime
2011-06-30 15:49 eblake Section => asctime
2011-06-30 15:49 eblake Page Number => 590
2011-06-30 15:49 eblake Line Number => 20346
2011-06-30 15:49 eblake Interp Status => ---
2011-06-30 15:49 eblake Tag Attached: c99
2011-06-30 16:47 eblake Note Added: 0000874
2011-06-30 17:02 eblake Note Added: 0000875
2011-08-04 16:27 eblake Note Added: 0000920
2011-08-04 16:35 nick Note Added: 0000921
2011-08-04 16:52 eblake Note Added: 0000922
2011-08-11 15:22 msbrown Interp Status --- => Pending
2011-08-11 15:22 msbrown Note Added: 0000934
2011-08-11 15:22 msbrown Status Under Review => Interpretation Required
2011-08-11 15:22 msbrown Resolution Open => Accepted As Marked
2011-08-11 15:23 msbrown Final Accepted Text => See Note: 0000934
2011-08-11 15:23 msbrown Note Added: 0000935
2011-08-11 15:40 Don Cragun Tag Attached: issue8
2012-06-29 16:19 ajosey Interp Status Pending => Proposed
2012-06-29 16:19 ajosey Note Added: 0001302
2012-08-30 09:11 ajosey Interp Status Proposed => Approved
2012-08-30 09:11 ajosey Note Added: 0001343
2020-03-05 15:07 geoffclare Status Interpretation Required => Applied

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker