View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000389 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2011-03-09 16:47 | 2013-04-16 13:06 |
| Reporter | geoffclare | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | Closed | Resolution | Accepted | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | perror | ||||
| Page Number | 1398 | ||||
| Line Number | 45795 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000389:0000690 | ||||
| Summary | 0000389: Handling errors during a perror() call | ||||
| Description | Since perror() writes to stderr, it can encounter the same error conditions as fputc(c, stderr) such as ENOSPC or EPIPE. The standard does not say anything about these errors. There is an obvious problem with determining whether an error occurred during a call to perror(). Since it reports the value of errno, applications can't use the method that is usually used for functions that do not return a value, namely setting errno to zero before the call and checking if it is non-zero afterwards. The best that could be done with errno alone would be to check whether errno is different after the call to the value it had before. However this has two problems: it relies on perror() not changing errno on success, which the standard currently does not require, and if errno has not changed this can mean either that perror() succeeded or that it encountered an error which produced the same errno value. However, errno does not have to be used alone: there is also ferror(). This could either be used to distinguish between the success and same-errno cases if errno hasn't changed, or it could be used as the primary method of detection. Using the latter would mean there is no need to require that perror() does not change errno on success. It is not clear to me whether perror() is currently required to set the error indicator if it encounters an error. Although not mentioned on the perror() page, there probably is such a requirement as a result of this statement in 2.5 Standard I/O Streams: "All input takes place as if bytes were read by successive calls to fgetc(); all output takes place as if bytes were written by successive calls to fputc()." Also in C99 the description of FILE in 7.19.1 might be regarded as a general requirement on all stream I/O functions to set the error indicator when a read/write error occurs: "an object type capable of recording all the information needed to control a stream, including its file position indicator, a pointer to its associated buffer (if any), an error indicator that records whether a read/write error has occurred, and an end-of-file indicator that records whether the end of the file has been reached" If 2.5 is sufficient to derive the requirement, then the only difference that this C99 question makes is whether CX shading should be used on the relevant text. For the moment I have included CX shading on the proposed text. | ||||
| Desired Action | After line 45791 add two new paragraphs, extending the CX shading to include them: On error, perror() shall set the error indicator for the stream to which stderr points, and shall set errno to indicate the error. Since no value is returned, an application wishing to check for error situations should call clearerr(stderr) before calling perror(), and after the call save the value of errno and call ferror(stderr) to check whether the error indicator has been set. If the error indicator has been set, the saved value of errno indicates which error occurred. At line 45795 change the ERRORS section from: No errors are defined. to: [CX] Refer to [xref to fputc()]. [/CX] At line 45810 change the APPLICATION USAGE section from: None. to: When using ferror() to detect whether perror() encountered an error, it is necessary to save the value of errno before the call to ferror() since this call can change the value of errno. Application writers may prefer to use alternative interfaces instead of perror(), such as strerror_r() in combination with fprintf(). | ||||
| Tags | c99, tc1-2008 | ||||
|
|
Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in the Desired Action field. |
|
|
Interpretation proposed 15 Mar 2011 for final 30 day review |
|
|
The same treatment is needed for psiginfo(). |
|
|
The interpretation is now approved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-03-09 16:47 | geoffclare | New Issue | |
| 2011-03-09 16:47 | geoffclare | Status | New => Under Review |
| 2011-03-09 16:47 | geoffclare | Assigned To | => ajosey |
| 2011-03-09 16:47 | geoffclare | Name | => Geoff Clare |
| 2011-03-09 16:47 | geoffclare | Organization | => The Open Group |
| 2011-03-09 16:47 | geoffclare | Section | => perror |
| 2011-03-09 16:47 | geoffclare | Page Number | => 1398 |
| 2011-03-09 16:47 | geoffclare | Line Number | => 45795 |
| 2011-03-09 16:47 | geoffclare | Interp Status | => --- |
| 2011-03-10 16:17 | nick | Tag Attached: c99 | |
| 2011-03-10 16:21 | Don Cragun | Interp Status | --- => Pending |
| 2011-03-10 16:21 | Don Cragun | Note Added: 0000690 | |
| 2011-03-10 16:21 | Don Cragun | Status | Under Review => Interpretation Required |
| 2011-03-10 16:21 | Don Cragun | Resolution | Open => Accepted |
| 2011-03-10 16:21 | Don Cragun | Description Updated | |
| 2011-03-10 16:21 | Don Cragun | Desired Action Updated | |
| 2011-03-10 16:22 | Don Cragun | Final Accepted Text | => See 0000389:0000690 |
| 2011-03-10 16:24 | Don Cragun | Tag Attached: tc1-2008 | |
| 2011-03-15 14:44 | ajosey | Interp Status | Pending => Proposed |
| 2011-03-15 14:44 | ajosey | Note Added: 0000699 | |
| 2011-03-17 15:31 | eblake | Note Added: 0000710 | |
| 2011-03-21 12:06 | geoffclare | Relationship added | related to 0000399 |
| 2011-03-31 16:51 | eblake | Relationship added | related to 0000401 |
| 2011-04-26 15:09 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-26 15:09 | ajosey | Note Added: 0000762 | |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
