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
0001132 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2017-03-24 23:45 2019-10-31 11:41
Reporter yousong View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Yousong Zhou
User Reference
Section pthread_sigmask
Page Number 1735
Line Number 56259
Interp Status ---
Final Accepted Text See Note: 0004124.
Summary 0001132: Whether the 'how' argument must be one of the three defined value should be clarified
Description The ERRORS section says it "shall fail if:

  The value of the how argument is not equal to one of the defined values.

But earlier in the page in DESCRIPTION section, it also says

  If set is a null pointer, the value of the argument how is not significant and the thread's signal mask shall be unchanged;

which is not clear whether 'how' is still required to be a defined value, or any value will do.
Desired Action Clarify in the document about acceptable values of the 'how' argument when 'set' is NULL. Specifically, what is the expected return value of the following function call

  pthread_sigmask(0, NULL, &oset);
Tags tc3-2008
Attached Files

- Relationships

-  Notes
shware_systems (reporter)
2017-03-25 07:53

Any value will do. The shall fail test for EINVAL occurs after checking for set being NULL, by use of the "not significant" phrasing. The conforming return is 0 for the example in the desired action, whether oset is a reference or NULL, in keeping with use of the interface as a reporting only function. When set and oset are both NULL the interface just wastes some processor cycles. The first call returns in oset the mask inherited from the pthread_create() call, so there is no "No old mask to return" error. Other return values are plausible as platform dependent extensions, but those would be for the platform to document, not the standard.
nsz (reporter)
2017-03-25 11:52

The current text requires failure with EINVAL if how is not SIG_BLOCK, SIG_SETMASK, SIG_UNBLOCK.

If that's not the intended behaviour then the text must change.
shware_systems (reporter)
2017-03-25 21:00

It would make it clearer to change it to a 'may fail' from 'shall fail', that's all I see. The 'shall return 0 upon success' part of Return Value I see as overriding the 'shall fail' part of the Errors section already so changing it isn't entirely a must, as simply getting the old mask can always succeed. For the example, a 0 or other arbitrary number might be the numerical value for one of the how constants, after all.

A missing 'may fail' error, for sigprocmask(), is detecting it isn't being called by the main thread of a process on an attempt to change the mask. This is left unspecified; to me the relationship to _POSIX_THREADS options being in effect during a compile could be clearer. Another 'may fail' one, on implementations supporting RTTI, for both is ENOBUFS, for the corner case of using (0,NULL,(sigset_t *)-1) as the arguments. Just because the old mask always can be retrieved doesn't mean it can be stored successfully, iow.
Don Cragun (manager)
2018-09-13 15:24

On P1735, L56259 (2016 edition) in the pthread_sigmask() ERRORS section, change:
The value of the how argument is not equal to one of the defined values.

The set argument is not a null pointer and the value of the how argument is not equal to one of the defined values.

- Issue History
Date Modified Username Field Change
2017-03-24 23:45 yousong New Issue
2017-03-24 23:45 yousong Status New => Under Review
2017-03-24 23:45 yousong Assigned To => ajosey
2017-03-24 23:45 yousong Name => Yousong Zhou
2017-03-24 23:45 yousong Section => pthread_sigmask
2017-03-24 23:45 yousong Page Number => 42
2017-03-24 23:45 yousong Line Number => 42
2017-03-24 23:45 yousong Issue Monitored: yousong
2017-03-25 07:53 shware_systems Note Added: 0003651
2017-03-25 11:52 nsz Note Added: 0003652
2017-03-25 21:00 shware_systems Note Added: 0003653
2018-09-13 15:24 Don Cragun Note Added: 0004124
2018-09-13 15:25 Don Cragun Interp Status => ---
2018-09-13 15:25 Don Cragun Final Accepted Text => See Note: 0004124.
2018-09-13 15:25 Don Cragun Status Under Review => Resolved
2018-09-13 15:25 Don Cragun Resolution Open => Accepted As Marked
2018-09-13 15:25 Don Cragun Tag Attached: tc3-2008
2018-09-13 15:26 Don Cragun Page Number 42 => 1735
2018-09-13 15:26 Don Cragun Line Number 42 => 56259
2018-09-13 15:27 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2
2019-10-31 11:41 geoffclare Status Resolved => Applied

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