Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000389 [1003.1(2008)/Issue 7] System Interfaces Objection Omission 2011-03-09 16:47 2013-04-16 13:06
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section perror
Page Number 1398
Line Number 45795
Interp Status Approved
Final Accepted Text See Note: 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.


    [CX] Refer to [xref to fputc()]. [/CX]

At line 45810 change the APPLICATION USAGE section from:



    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
Attached Files

- Relationships
related to 0000399Closedajosey Handling errors during a psiginfo() or psignal() call 
related to 0000401Closedajosey ferror should not modify errno 

-  Notes
Don Cragun (manager)
2011-03-10 16:21

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.


Notes to the Editor (not part of this interpretation):
Make the changes suggested in the Desired Action field.
ajosey (manager)
2011-03-15 14:44

Interpretation proposed 15 Mar 2011 for final 30 day review
eblake (manager)
2011-03-17 15:31

The same treatment is needed for psiginfo().
ajosey (manager)
2011-04-26 15:09

The interpretation is now approved.

- Issue History
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 Note: 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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker