0000389: Handling errors during a perror() call - Austin Group Defect Tracker

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.

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

Relationships

related to	0000399	Closed	ajosey	Handling errors during a psiginfo() or psignal() call
related to	0000401	Closed	ajosey	ferror should not modify errno

Notes
(0000690) 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. Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in the Desired Action field.

(0000699) ajosey (manager) 2011-03-15 14:44	Interpretation proposed 15 Mar 2011 for final 30 day review

(0000710) eblake (manager) 2011-03-17 15:31	The same treatment is needed for psiginfo().

(0000762) 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