|Anonymous | Login||2023-12-07 10:12 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Organization||The Open Group|
|Final Accepted Text||See Note: 0000690|
|Summary||0000389: Handling errors during a perror() call|
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
After line 45791 add two new paragraphs, extending the CX shading to
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
Don Cragun (manager)
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.
|Interpretation proposed 15 Mar 2011 for final 30 day review|
|The same treatment is needed for psiginfo().|
|The interpretation is now approved.|
|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|