 Relationships |
||||||
|
||||||
| Anonymous | Login | 2023-06-04 09:59 UTC |
| 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 | ||
| 0000382 | [1003.1(2008)/Issue 7] System Interfaces | Editorial | Clarification Requested | 2011-02-18 22:24 | 2013-04-16 13:06 | ||
| Reporter | jilles | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Closed | ||||||
| Name | Jilles Tjoelker | ||||||
| Organization | |||||||
| User Reference | |||||||
| Section | strerror | ||||||
| Page Number | 2000 | ||||||
| Line Number | 63267 | ||||||
| Interp Status | Approved | ||||||
| Final Accepted Text | see Note: 0000693 | ||||||
| Summary | 0000382: may strerror(0) fail with EINVAL? | ||||||
| Description |
Reading XSH 2.3 Error Numbers and the strerror page, it looks like strerror(), strerror_l() and strerror_r() may fail with [EINVAL] if 0 is passed for errnum (for strerror() and strerror_l() at least, a string shall still be returned). Although zero is a possible value for errno and indicates success for pthread_create() and similar functions, it is not an error number. Accordingly, FreeBSD's strerror() and strerror_r() fail with [EINVAL] for errnum==0 (while still returning a string). FreeBSD has received a bug report that this causes POSIX/SUS testsuites to fail: http://www.freebsd.org/cgi/query-pr.cgi?pr=151316 [^] Most other implementations (tested NetBSD, glibc, Solaris) succeed for errnum==0. In any case, I think calling strerror(0) (or equivalent strerror_l()/strerror_r()) is almost always an application bug, violating the recommendation that errno only be examined if indicated to be valid by a function's return value. |
||||||
| Desired Action |
One of these three: 1. If I am interpreting something incorrectly and there is language that says strerror(0) must not fail, please point me to it. 2. If strerror(0) is supposed to succeed, change the condition for [EINVAL] from The value of errnum is not a valid error number. to something like The value of errnum is neither a valid error number nor zero. 3. If strerror(0) may fail, clarify this and adjust test suites. |
||||||
| Tags | c99, tc1-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
||||||
|
||||||
|
Notes |
|
|
(0000686) eblake (manager) 2011-03-03 17:42 |
Consensus on the Mar 3 2011 call was that an interpretation is needed, and that while the standard does not currently require it, the intent was that strerror(0) should be required to succeed, because there are existing applications that rely on this behavior. We ran out of time in the call to complete a full interpretation, but possible wording for this would be along the lines of replacing line 63253 with the following: If the value of errnum is a valid error number, the message string shall indicate what error occurred; if the value of errnum is zero, the message string shall either be of zero length or indicate that no error occurred; otherwise, if these functions complete successfully, the message string shall indicate that an unknown error occurred. However, more work is needed to polish this into a formal change. In particular, the group noted that strerror_r, as well as several other interfaces (getgrgid_r, ttyname_r, and probably others) should require ERANGE failures for too-small buffers as a 'shall fail' rather than a 'may fail' condition. In particular, strerror_r(0,NULL,0) should fail with ERANGE (and not EINVAL). It was also pointed out that this implementation of strerror would comply with C99 but not POSIX: char *strerror(int errnum) { return ""; } because the POSIX wording that requires a message indicating which error occurred for valid errnum values only occurs in <CX> shading. |
|
(0000693) eblake (manager) 2011-03-10 17:09 edited on: 2011-03-10 17:14 |
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- While the standard does not currently require it, the intent was that strerror(0) should be required to succeed, and there are existing applications that rely on this behavior. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Replace the paragraph at line 63253 [XSH strerror], still with CX shading: If the value of errnum is a valid error number, the message string shall indicate what error occurred; if the value of errnum is zero, the message string shall either be an empty string or indicate that no error occurred; otherwise, if these functions complete successfully, the message string shall indicate that an unknown error occurred. At line 63267, change is not a valid error number. to is neither a valid error number nor zero. At line 63303, add a new paragraph: Some applications rely on being able to set errno to 0 before calling a function with no reserved value to indicate an error, then call strerror(errno) afterwards to detect whether an error occurred (because errno changed) or indicate success (because errno remained zero). This usage pattern requires that strerror(0) succeed with useful results. Previous versions of the standard did not specify the behavior when errnum is zero. |
|
(0000700) ajosey (manager) 2011-03-15 14:44 |
Interpretation proposed 15 Mar 2011 for final 30 day review |
|
(0000763) ajosey (manager) 2011-04-26 15:10 |
The interpretation is now approved. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-02-18 22:24 | jilles | New Issue | |
| 2011-02-18 22:24 | jilles | Status | New => Under Review |
| 2011-02-18 22:24 | jilles | Assigned To | => ajosey |
| 2011-02-18 22:25 | jilles | Name | => Jilles Tjoelker |
| 2011-02-18 22:25 | jilles | Section | => strerror |
| 2011-02-18 22:25 | jilles | Page Number | => 2000 |
| 2011-02-18 22:25 | jilles | Line Number | => 63267 |
| 2011-03-03 17:42 | eblake | Note Added: 0000686 | |
| 2011-03-03 17:53 | nick | Tag Attached: c99 | |
| 2011-03-10 17:09 | eblake | Note Added: 0000693 | |
| 2011-03-10 17:10 | eblake | Tag Attached: tc1-2008 | |
| 2011-03-10 17:11 | eblake | Interp Status | => Pending |
| 2011-03-10 17:11 | eblake | Final Accepted Text | => see Note: 0000693 |
| 2011-03-10 17:11 | eblake | Status | Under Review => Interpretation Required |
| 2011-03-10 17:11 | eblake | Resolution | Open => Accepted |
| 2011-03-10 17:12 | eblake | Resolution | Accepted => Accepted As Marked |
| 2011-03-10 17:14 | eblake | Note Edited: 0000693 | |
| 2011-03-15 14:44 | ajosey | Interp Status | Pending => Proposed |
| 2011-03-15 14:44 | ajosey | Note Added: 0000700 | |
| 2011-03-17 21:59 | eblake | Relationship added | related to 0000398 |
| 2011-04-26 15:10 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-26 15:10 | ajosey | Note Added: 0000763 | |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
