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
0000399 [1003.1(2008)/Issue 7] System Interfaces Objection Omission 2011-03-21 12:05 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 psiginfo
Page Number 1528
Line Number 49335
Interp Status Approved
Final Accepted Text See Note: 0000733
Summary 0000399: Handling errors during a psiginfo() or psignal() call
Description Since psiginfo() and psignal() write to stderr, they can encounter the
same error conditions as fputc(c, stderr) such as ENOSPC or EPIPE.
The standard does not say anything about these errors.

Since psiginfo() and psignal() do not return a value, applications
should use the usual method to detect errors of setting errno to zero
before the call and checking if it is non-zero afterwards. This means
requiring psiginfo() and psignal() not to change errno on success.

It is not clear to me whether psiginfo() are psignal() are currently
required to set the error indicator if they encounter an error.
Although not mentioned on the psiginfo() 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()."

If this requirement is made explicit on the psiginfo() page then the
application usage section should advise on how to use ferror() as an
alternative method to detect whether psiginfo() or psignal()
encountered an error. (This is the method proposed for perror() in
bug 0000389, however it is only proposed there because the usual
errno method cannot be used with perror() whereas it can be used with
psiginfo() and psignal().)
Desired Action After line 49331 add three new paragraphs:

    The psiginfo() and psignal() functions shall not change the
    setting of errno if successful.

    On error, the psiginfo() and psignal() functions 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 set errno to 0, then call psiginfo() or
    psignal(), then check errno.

At line 49335 change the ERRORS section from:

    No errors are defined.


    Refer to [xref to fputc()].

At line 49339 change the APPLICATION USAGE section from:



    As an alternative to setting errno to zero before the call and
    checking if it is non-zero afterwards, applications can use
    ferror() to detect whether psiginfo() or psignal() encountered an
    error. An application wishing to use this method to check for
    error situations should call clearerr(stderr) before calling
    psiginfo() or psignal() 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. Note that it is necessary
    to save the value of errno before the call to ferror() since this
    call can change the value of errno.
Tags tc1-2008
Attached Files

- Relationships
related to 0000389Closedajosey Handling errors during a perror() call 
related to 0000401Closedajosey ferror should not modify errno 

-  Notes
Don Cragun (manager)
2011-03-31 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-06-16 10:15

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

The interpretation is now approved.

- Issue History
Date Modified Username Field Change
2011-03-21 12:05 geoffclare New Issue
2011-03-21 12:05 geoffclare Status New => Under Review
2011-03-21 12:05 geoffclare Assigned To => ajosey
2011-03-21 12:05 geoffclare Name => Geoff Clare
2011-03-21 12:05 geoffclare Organization => The Open Group
2011-03-21 12:05 geoffclare Section => psiginfo
2011-03-21 12:05 geoffclare Page Number => 1528
2011-03-21 12:05 geoffclare Line Number => 49335
2011-03-21 12:05 geoffclare Interp Status => ---
2011-03-21 12:06 geoffclare Relationship added related to 0000389
2011-03-31 16:21 Don Cragun Note Added: 0000733
2011-03-31 16:22 Don Cragun Tag Attached: tc1-2008
2011-03-31 16:24 Don Cragun Interp Status --- => Pending
2011-03-31 16:24 Don Cragun Final Accepted Text => See Note: 0000733
2011-03-31 16:24 Don Cragun Status Under Review => Interpretation Required
2011-03-31 16:24 Don Cragun Resolution Open => Accepted
2011-03-31 16:24 Don Cragun Description Updated
2011-03-31 16:24 Don Cragun Desired Action Updated
2011-03-31 16:51 eblake Relationship added related to 0000401
2011-06-16 10:15 ajosey Interp Status Pending => Proposed
2011-06-16 10:15 ajosey Note Added: 0000844
2011-07-29 06:14 ajosey Interp Status Proposed => Approved
2011-07-29 06:14 ajosey Note Added: 0000908
2013-04-16 13:06 ajosey Status Interpretation Required => Closed

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