View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000469 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2011-06-30 15:49 | 2024-06-11 08:53 |
| Reporter | eblake | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| 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 0000469: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 | ||||
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 . |
|
|
We need to verify that C1X doesn't change the wording before it is adopted. |
|
|
Interpretation proposed 29 June 2012 for final 45 day review |
|
|
Interpretation approved 30 Aug 2012 |
| 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 |
