0000399: Handling errors during a psiginfo() or psignal() 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

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.

to:

    Refer to [xref to fputc()].

At line 49339 change the APPLICATION USAGE section from:

    None.

to:

    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

Relationships

related to	0000389	Closed	ajosey	Handling errors during a perror() call
related to	0000401	Closed	ajosey	ferror should not modify errno

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

(0000844) ajosey (manager) 2011-06-16 10:15	Interpretation proposed 16 June 2011 for final 30 day review

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