View Issue Details

IDProjectCategoryView StatusLast Update
00004691003.1(2008)/Issue 7System Interfacespublic2024-06-11 08:53
Reportereblake Assigned Toajosey  
PrioritynormalSeverityEditorialTypeError
Status ClosedResolutionAccepted As Marked 
NameEric Blake
OrganizationRed Hat
User Referenceebb.asctime
Sectionasctime
Page Number590
Line Number20346
Interp StatusApproved
Final Accepted TextSee 0000469:0000934
Summary0000469: asctime and integer overflow
Descriptionasctime is undefined if it encounters INT_MAX overflow on tm_year, but
the text describing that uses the wrong offset.
Desired ActionAt line 20346, change "if timeptr−>tm_year exceeds {INT_MAX}−1990,"
to "if timeptr−>tm_year exceeds {INT_MAX}−1900,"
Tagsc99, issue8

Activities

eblake

2011-06-30 16:47

manager   bugnote:0000874

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).

eblake

2011-06-30 17:02

manager   bugnote:0000875

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.

eblake

2011-08-04 16:27

manager   bugnote:0000920

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.

nick

2011-08-04 16:35

manager   bugnote:0000921

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.

eblake

2011-08-04 16:52

manager   bugnote:0000922

Regarding 0000469: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.

msbrown

2011-08-11 15:22

manager   bugnote:0000934

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 0000469:0000921 .

msbrown

2011-08-11 15:23

manager   bugnote:0000935

We need to verify that C1X doesn't change the wording before it is adopted.

ajosey

2012-06-29 16:19

manager   bugnote:0001302

Interpretation proposed 29 June 2012 for final 45 day review

ajosey

2012-08-30 09:11

manager   bugnote:0001343

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 0000469: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
2024-06-11 08:53 agadmin Status Applied => Closed