Austin Group Defect Tracker

Aardvark Mark III


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
related to 0000398Interpretation Requiredajosey mandatory ERANGE failures on insufficient buffer size 

-  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
Powered by Mantis Bugtracker