|Anonymous | Login | Signup for a new account||2018-02-17 19:52 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Final Accepted Text|
|Summary||0001132: Whether the 'how' argument must be one of the three defined value should be clarified|
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.
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.|
|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.|
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.
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.
|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|