Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000401 [1003.1(2008)/Issue 7] System Interfaces Objection Omission 2011-03-31 16:50 2013-04-16 13:06
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Eric Blake
Organization Red Hat
User Reference ebb.ferror
Section ferror
Page Number 835
Line Number 27871
Interp Status Approved
Final Accepted Text Note: 0000747
Summary 0000401: ferror should not modify errno
Description The standard states that unless explicitly documented otherwise, the value
of errno is unspecified after a successful function call. However, it is
common to use ferror() to check whether other stream-based functions failed,
and is commonly implemented without modifying errno, therefore it would be
nice to guarantee that errno is unchanged over a successful call, rather
than requiring that applications save errno before ferror() and then rely
on a non-zero result to learn whether the previously saved value is useful.
For consistency, feof() and clearerr() can be given the same treatment.

Note that as an extension, an implementation may guarantee that ferror
will fail and set errno on detection of an invalid stream argument, but
this is already unspecified behavior and does not need further mention
in the standard. There is still no return value nor errno value reserved
for this case in the standard, so an implementation providing such an
extension would also document that setting errno to 0 prior to ferror()
and observing a change in errno could be used to detect such failures.
Desired Action At line 22502 [XSH clearerr DESCRIPTION], add a sentence with CX shading:

<CX>The clearerr() function shall not change the setting of errno if
stream is valid.</CX>

At line 27807 [XSH feof DESCRIPTION], add a sentence with CX shading:

<CX>The feof() function shall not change the setting of errno if
stream is valid.</CX>

At line 27871 [XSH ferror DESCRIPTION], add a sentence with CX shading:

<CX>The ferror() function shall not change the setting of errno if
stream is valid.</CX>



Optional: If this is approved at the same time as 0000389 and 0000399,
then those resolutions should also be simplified accordingly:

For 0000389, change the proposed wording at line 45791 to:
    ... an application wishing to check for error situations should
    call clearerr(stderr) before calling perror(), then if
    ferror(stderr) returns non-zero, the value of errno indicates
    which error occurred.
and delete the first proposed sentence at 45810 (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.)

For 0000399, change the proposed wording at line 49339 to:
    ... An application wishing to use this method to check for
    error situations should call clearerr(stderr) before calling
    psiginfo() or psignal(), then if ferror(stderr) returns non-zero,
    the value of errno indicates which error occurred.
Tags tc1-2008
Attached Files

- Relationships
related to 0000389Closedajosey Handling errors during a perror() call 
related to 0000399Closedajosey Handling errors during a psiginfo() or psignal() call 
related to 0000384Closedajosey the stdarg macros should not modify errno 

-  Notes
(0000747)
msbrown (manager)
2011-04-21 15:40

 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:
-------------
This change should not break any known existing implementations, and will aid application developers.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Use the instructions in the Desired Action section, including the optional sections.
(0000846)
ajosey (manager)
2011-06-16 10:16

 Interpretation proposed 16 June 2011 for final 30 day review
(0000906)
ajosey (manager)
2011-07-29 06:14

 The interpretation is now approved.

- Issue History
Date Modified Username Field Change
2011-03-31 16:50 eblake New Issue
2011-03-31 16:50 eblake Status New => Under Review
2011-03-31 16:50 eblake Assigned To => ajosey
2011-03-31 16:50 eblake Name => Eric Blake
2011-03-31 16:50 eblake Organization => Red Hat
2011-03-31 16:50 eblake User Reference => ebb.ferror
2011-03-31 16:50 eblake Section => ferror
2011-03-31 16:50 eblake Page Number => 835
2011-03-31 16:50 eblake Line Number => 27871
2011-03-31 16:50 eblake Interp Status => ---
2011-03-31 16:51 eblake Relationship added related to 0000389
2011-03-31 16:51 eblake Relationship added related to 0000399
2011-03-31 16:53 eblake Desired Action Updated
2011-04-21 15:40 msbrown Interp Status --- => Pending
2011-04-21 15:40 msbrown Note Added: 0000747
2011-04-21 15:40 msbrown Type Omission => Enhancement Request
2011-04-21 15:40 msbrown Status Under Review => Interpretation Required
2011-04-21 15:40 msbrown Resolution Open => Future Enhancement
2011-04-21 15:41 msbrown Final Accepted Text => Note: 0000747
2011-04-21 15:41 msbrown Type Enhancement Request => Omission
2011-04-21 15:41 msbrown Resolution Future Enhancement => Accepted As Marked
2011-04-21 15:43 nick Tag Attached: tc1-2008
2011-06-16 10:16 ajosey Interp Status Pending => Proposed
2011-06-16 10:16 ajosey Note Added: 0000846
2011-07-29 06:14 ajosey Interp Status Proposed => Approved
2011-07-29 06:14 ajosey Note Added: 0000906
2013-04-16 13:06 ajosey Status Interpretation Required => Closed
2016-07-28 15:06 eblake Relationship added related to 0000384

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