Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001132 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2017-03-24 23:45 2017-03-25 21:00
Reporter yousong View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Yousong Zhou
Organization
User Reference
Section pthread_sigmask
Page Number 42
Line Number 42
Interp Status ---
Final Accepted Text
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:

  [EINVAL]
  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 No tags attached.
Attached Files

- Relationships

-  Notes
(0003651)
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.
(0003652)
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.
(0003653)
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.

- 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


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