NOTICE: This is an unapproved draft, it is a work in progress, subject to change. (Last update 22 Nov 2002) (Updated Dec 9 to add ERNs 44-46 inc) (Updated 15 Jan to add ERN 47) (Updated 17 Jan after telecon) (Updated 31 Jan after telecon, including adding ERNs 48-52) (Updated 7 Feb after telecon) (Updated 19 Feb ,add new ERNS 53-62) (Updated 21 Feb ,updated after telecon) (Updated 28 Feb, updated after telecon) (Updated 14 Mar,add 72 and 73) (Updated 31 Mar, also add new ERNs) (Updated 11 Apr, after telcon) (Updated 23 Apr, add new rdvk) (Updated 7 May, add new rdvk) (Updated 21 May, add new rdvk, and update TC2 candidate list) (Updated 28 May, update after telco) (Updated 8 June, update after telco,add new rdvk) (Updated 10 June, update add new rdvk) (Updated 13 June, update after telco) (Updated 20 June, update after telco, and add new rdvk) (Updated 14 July, update after telco, and add new rdvk) (Updated 18 July, update after telco, and add new rdvk) (Updated 23 July, update maths examples and add new rdvk) (Updated 24 July, add 3 new rdvk before the telco) (Updated 25 July, update after telco, also updated mtk examples) (Updated 31 July, update loic examples,add new inbound) (Updated 1 August, after meeting) (Updated 4 August, add missing ERN 136) (Updated 6 August, add new ERN) (Updated 8 August, after telco) (Updated 13 August, add new ERNs) (Updated 15 August, after telco , and add final inbound for TC2) (Updated 22 August, after telco) (Updated 29 August, after telco) (Updated 3 Sep, after telco) (Updated 4 Sep, after telco) (Updated 19 Sep, after telco) (Updated 26 Sep, after telco) Note the tag "TC" denotes this is a proposed candidate item for a future technical corrigendum. _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 gwc@opengroup.org Defect in XSH 2.2.2 (rdvk# 39) [math FP prefix] Mon, 7 Oct 2002 20:05:21 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 18 Line: 660 Section: 2.2.2 Problem: Defect code : 1. Error The math.h page in XBD6 states "Additional implementation-defined floating-point classifications, with macro definitions beginning with FP_ and an uppercase letter, may also be specified by the implementation." However, there is no corresponding entry in the table of allowed macro prefixes in XSH6. Action: Add the following line to the table on page 18, before line 660: FP_[A-Z] _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 drepper@redhat.com Defect in XSH aio_cancel() (rdvk# 31) {ud-process-1} Sat, 19 Oct 2002 05:46:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC The aio_cancel() function shall return the value AIO_CANCELED if [...] _____________________________________________________________________________ Page: 104 Line: 3898 Section: aio_cancel() Problem: Defect code : 1. Error The return value description of aio_cancel says: The aio_cancel() function shall return the value AIO_CANCELED to the calling process if [...] The use of process is wrong. The value is returned to the calling _thread_. Action: Change the beginning og the sentence starting on line 3898 to: The aio_cancel() function shall return the value AIO_CANCELED to the calling thread if [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 3 drepper@redhat.com Defect in XSH aio_fsync() (rdvk# 30) {ud-process-2} Sat, 19 Oct 2002 05:48:04 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Change the beginning og the sentence starting on line 3898 to: The aio_fsync() function shall return the value 0 if... _____________________________________________________________________________ Page: 107 Line: 4001 Section: aio_fsync() Problem: Defect code : 1. Error The return value description of aio_fsync says: The aio_fsync() function shall return the value 0 to the calling process if [...] The use of process is wrong. The value is returned to the calling _thread_. Action: Change the beginning og the sentence starting on line 3898 to: The aio_fsync() function shall return the value 0 to the calling thread if [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 drepper@redhat.com Defect in XSH aio_read() (rdvk# 29) {ud-process-3} Sat, 19 Oct 2002 05:54:41 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC If prioritized I/O is supported for this file, then the asynchronous operation shall be submitted at a priority equal to the scheduling priority of the process [TPS]or thread[/TPS] minus aiocbp->aio_reqprio. (Ed note: since this section is PIO shaded, this may cause a challenge to the shading) Possible alternative (editors to decide): PIO If prioritized I/O is supported for this file, then the asynchronous operation shall be submitted at a priority equal to a base scheduling priority minus aiocbp->reqprio. If Thread Priority Scheduling is not supported then the base scheduling priority is that of the calling process, PIO TPS otherwise the base scheduling priority is that of the calling thread. _____________________________________________________________________________ Page: 109 Line: 4045 Section: aio_read() Problem: Defect code : 1. Error The description of aio_read says: If prioritized I/O is supported for this file, then the asynchronous operation shall be submitted at a priority equal to the scheduling priority of the process minus aiocbp->aio_reqprio. The use of process is wrong. If threads are support the pthread_attr_setschedparam function is also support and then each thread can have its own priority. The problem here is also the marking. If no threads are support PIO is the correct marker. But if threads are supported the sentence becomes a requirement. The current marking is probably OK. Action: Change the sentence on line 4045: [...] at a priority equal to the scheduling priority of the thread minus aiocbp->aio_reqprio. _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 drepper@redhat.com Defect in XSH aio_read() (rdvk# 27) {ud-process-4} Sat, 19 Oct 2002 05:56:35 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Change the beginning of the sentence on line 4067 to: The aio_read() function shall return the value zero if... _____________________________________________________________________________ Page: 109 Line: 4067 Section: aio_read() Problem: Defect code : 1. Error The description of the return value of aio_read says: The aio_read() function shall return the value zero to the calling process if [...] Action: Change the beginning of the sentence on line 4067 to: The aio_read() function shall return the value zero to the calling thread if [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 drepper@redhat.com Defect in XSH aio_write() (rdvk# 26) {ud-process-5} Sat, 19 Oct 2002 05:59:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Take the same approach as per #4 _____________________________________________________________________________ Page: 115 Line: 4232 Section: aio_write() Problem: Defect code : 1. Error The description of aio_write says: [...] at a priority equal to the scheduling priority of the process minus aiocbp->aio_reqprio. This is the same problem as mentioned for aio_read() and whatever is decided for aio_read() has to be done here as well. Action: Change line 4232 to: at a priority equal to the scheduling priority of the thread minus aiocbp->aio_reqprio. _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 drepper@redhat.com Defect in XSH aio_write() (rdvk# 25) {ud-process-6} Sat, 19 Oct 2002 06:01:53 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC OK with the change, an alternate way for this specific case would be to remove the words "to the calling process" _____________________________________________________________________________ Page: 115 Line: 4255 Section: aio_write() Problem: Defect code : 1. Error The description of the return value of aio_write says: The aio_write() function shall return the value zero to the calling process if [...] The use of process is wrong, the value is returned to the calling thread. Action: Change the beginning of line 4255 to: The aio_write() function shall return the value zero to the calling thread if [...] _____________________________________________________________________________ COMMENT Enhancement Request Number 8 wollman@lcs.mit.edu Defect in XSH atexit (rdvk# 38) {GAW-2002g} Fri, 6 Sep 2002 20:02:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Go with Number 2 below. 1. Add to APPLICATION USAGE Since the behavior is undefined if the exit() function is called more than once, applications calling atexit() must ensure that their registered functions do not call exit() themselves. OR (alternative) 2. Add to APPLICATION USAGE section: Since the behavior is undefined if the exit() function is called more than once, portable applications calling atexit() must ensure that the exit() function is not called at normal process termination when all functions registered by the atexit() function are called. All functions registered by the atexit() function are called at normal process termination, which occurs by a call to the exit() function or a return from main() or on the last thread termination when the behavior is as if the implementation called exit() with a zero argument at thread termination time. If, at normal process termination, a function registered by the atexit() function is called and portable application needs to stop further exit() processing, it must call the _exit() function or the _Exit() function or one of the functions which cause abnormal process termination. _____________________________________________________________________________ Page: 136 Line: 4831 Section: atexit Problem: Defect code : 3. Clarification required The description of atexit() leaves unstated what happens when exit() is called from a function so registered Existing implementations seem to fall into two groups. The first group enters bottomless recursion; the second group prevents this recursion in some unspecified manner. I believe that the intent of the standard is not to constrain implementations with respect to the nature of processing atexit()-registered functions during normal process termination. (It would be nice if there were a standard way for such a function to indicate ``continue normal termination but substitute this exit status'', but this is clearly out of scope.) If this is the case, then the standard should prohibit functions registered with atexit() from calling exit() recursively. Action: Add after line 4841 a new paragraph: Functions registered with atexit() shall not call the exit() function. (Does this need to be CX-shaded? Presumably C has the same problem, hence the introduction of _Exit() in C99.) At line 4852 add to existing paragraph: If the function needs to prevent further processing, it must call _exit(), _Exit(), or one of the functions which cause abnormal process termination. _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 drepper@redhat.com Defect in XSH pthread_sigmask() (rdvk# 23) {ud-process-9} Sat, 19 Oct 2002 06:38:21 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Change beginning of line 9825 to: "SIG_IGN, and that the new process image inherits the signal mask of the thread that called exec in the old process image" (note to ed: it may be possible to clean up the use of exec - the exec family??) ---- Notes on decision: Response from email to general reflector (from DB): On the face of it, and in highly narrowed context, yes, the suggested fix is reasonable and appropriate. Take a step further out, though, and I wonder. First off, it's not clear that the framework of exec provides any basis for interpreting the word "unchanged". (And all this aside from the fact that rationale is formally inoperative commentary anyway.) The text relates the process of REPLACING one "process image" with another, though there are specific aspects that the new process image will inherit from the old. In particular, though, exec states that ALL threads terminate -- not "all but the calling thread". In other contexts where the new "process image" will have "unchanged" context, it merely says that the attributes "shall be the same in the new and old process images". (Hmm, one might take that to mean that it's also changes them in the old process image before wiping it out? ;-) [Sorry, there goes Hyde again].) I don't like this whole "process image" stuff, which is a locally invented term to convey information I believe is well covered by standard terms like "process" and "program". (Though POSIX seems to have lacked the latter, and that may have been the issue.) The general take here, including both the "all threads are terminated" and the header "The new process shall inherit" list on page 297, is that, in a formal sense, exec() creates a new process using pieces of the calling context. (Including, by definition, the process ID.) Otherwise why not simply say that it loads a new program into the process and resets some state? So nothing is "unchanged" across the call. Furthermore, the list on page 297 claims that the process signal mask and pending signals are "inherited" from "the calling process image". That's NORMATIVE text, and clearly needs to be fixed. Should we be clarifying the terminology here? Instead of all this "process image" stuff, why not simply say that exec() "loads a specified program into a process, which [may or may not be the original process but at least] inherits certain parts of that process state". I suppose we have no need to perform that level of cleanup. So, yes, more or less, the rationale in question should say that "the new process image inherits the signal mask of the thread that called exec in the old process image". Or words to that effect. _____________________________________________________________________________ Page: 301 Line: 9825 Section: pthread_sigmask() Problem: Defect code : 1. Error More "process signal mask" nonsense, this time in rationale. Action: Change beginning of line 9825 to: SIG_IGN, and that the thread signal mask be unchanged across an exec. _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 wollman@lcs.mit.edu Defect in XSH fchmod (rdvk# 40) {GAW-2002-fchmod} Tue, 22 Oct 2002 22:25:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The rationale for the wording we have at the moment is that some application developers may decide to use a platform extension, and the group that put the words together decided that it had meaning to allow such an application to be conforming. For example, consider that some application developers are contractually required to deliver a "conforming" application, this can and does happen, particularly in government contracts. If the application is not technically "conforming", then you don't get paid. Consensus of the first teleconference review was to leave as is. Subsequent mail discussions urged that some consideration could be given to bounding the unspecified operations, for example "calling the function will succeed but have an unspecified effect on the state of the socket or the filesystem object underlying the socket." (Note... "unspecified effect" could be none, and that or is an inclusive or.) The same would be applied to the typed memory -- we'd also need to look at the fdopen() page. This was discussed again on the 16 Jan teleconf, the counter argument was again that we did not want to narrow the unspecification down and that conforming applications should not use the feature. The item is still rejected. _____________________________________________________________________________ Page: 321 Line: 10521 Section: fchmod Problem: Defect code : 1. Error The text does not provide enough information to interpret the key word ``unspecified''. (Aardvark inspired by Wojtek Lerch.) Action: One of the following two changes should be made: (1) Replace ``unspecified'' with ``undefined''. (This is effectively a null change, since the standard is silent about precisely what is unspecified, so by the ``silence rule'' it must therefore be undefined. However, I do not think that it reflects the intent of the base document.) (2) Replace the entire paragraph with words to the effect of: If fildes refers to a socket, it is unspecified whether or not fchmod() [performs any action | has any visible effect] on the socket. Regardless of which change is taken, similar considerations apply to typed memory objects in the paragraph immediately preceding. (With either revised wording, the two paragraphs can be, and probably should be, coalesced into one.) I think that the overall intent is that the result of fchmod() should always be defined, but implementation choices outside the scope of the Standard may result in fchmod() not having a meaningful effect on some kinds of file descriptors. _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 drepper@redhat.com Defect in XSH fclose() (rdvk# 22) {ud-process-10} Sat, 19 Oct 2002 06:47:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Notes on decision: The group considered the response below, but still believe we should take the original action, (they had specific difficulty with the word completion) [The following comment back from Dave B This (and many following) are among the cases where dropping "calling thread/calling process" wouldn't be quite right. But why can't we simply say that "completion of the write operation" will be delayed without worrying about the context within which the function was called?] _____________________________________________________________________________ Page: 325 Line: 10655 Section: fclose() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the write operation. It's not the process which would get delayed, but the calling thread. Action: Change line 10655 to: thread would be delayed in the write operation. _____________________________________________________________________________ OBJECTION Enhancement Request Number 12 drepper@redhat.com Defect in XSH fclose() (rdvk# 21) {ud-process-11} Sat, 19 Oct 2002 06:51:22 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC (should be fflush) _____________________________________________________________________________ Page: 358 Line: 11615 Section: fclose() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the write operation. It's not the process which would get delayed, but the calling thread. Action: Change line 11615 to: thread would be delayed in the write operation. _____________________________________________________________________________ OBJECTION Enhancement Request Number 13 drepper@redhat.com Defect in XSH fclose() (rdvk# 20) {ud-process-12} Sat, 19 Oct 2002 06:52:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC (fclose should be fgetc) _____________________________________________________________________________ Page: 362 Line: 11731 Section: fclose() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the fgetc() operation. It's not the process which would get delayed, but the calling thread. Action: Change line 11731 to: thread would be delayed in the fgetc() operation. _____________________________________________________________________________ OBJECTION Enhancement Request Number 14 drepper@redhat.com Defect in XSH fclose() (rdvk# 19) {ud-process-13} Sat, 19 Oct 2002 06:53:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC fclose->fgetwc _____________________________________________________________________________ Page: 368 Line: 11898 Section: fclose() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the fgetwc() operation. It's not the process which would get delayed, but the calling thread. Action: Change line 11898 to: thread would be delayed in the fgetwc() operation. _____________________________________________________________________________ COMMENT Enhancement Request Number 15 ajosey@opengroup.org Defect in XSH fpathconf (rdvk# 34) {_PC.adv.stuff} Tue, 17 Sep 2002 11:33:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC A/M Add the number 10 in the requirements column for all 5 ADV names in the table on lines 12861-12865. After line 12893, add: 10. If path or fildes does not refer to a regular file, it is unspecified whether an implementation supports an association of the variable name with the specified file. If an implementation supports such an association for other than a regular file, the value returned is unspecified. Note that it was the intention of .1d that these variables only apply to regular files, but the above requirement allows that an implementation may choose to implement the advisory semantics on other file types unique to that implementation (e.g. a character special device.) Frank _____________________________________________________________________________ Page: 397 Line: 12861 Section: fpathconf Problem: Defect code : 1. Error The Requirements column for the items under the advisory option is empty. It should have an entry. Action: No solution proposed apart from requesting that someone who knows provide the information. _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 drepper@redhat.com Defect in XSH fputc() (rdvk# 18) {ud-process-14} Sat, 19 Oct 2002 06:58:23 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 414 Line: 13577 Section: fputc() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the write operation. It's not the process which would get delayed, but the calling thread. Action: Change line 13577 to: thread would be delayed in the write operation. _____________________________________________________________________________ OBJECTION Enhancement Request Number 17 drepper@redhat.com Defect in XSH fputwc() (rdvk# 17) {ud-process-15} Sat, 19 Oct 2002 06:59:31 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 418 Line: 13694 Section: fputwc() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the write operation. It's not the process which would get delayed, but the calling thread. Action: Change line 13694 to: thread would be delayed in the write operation. _____________________________________________________________________________ OBJECTION Enhancement Request Number 18 drepper@redhat.com Defect in XSH fseek() (rdvk# 15) {ud-process-16} Sat, 19 Oct 2002 07:01:08 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 441 Line: 14488 Section: fseek() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the write operation. It's not the process which would get delayed, but the calling thread. Action: Change the end of line 14488 to: and the thread would be _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 drepper@redhat.com Defect in XSH fsetpos() (rdvk# 16) {ud-process-17} Sat, 19 Oct 2002 07:06:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 443 Line: 14569 Section: fsetpos() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed in the write operation. It's not the process which would get delayed, but the calling thread. Action: Change the end of line 14569 to: and the thread would be _____________________________________________________________________________ COMMENT Enhancement Request Number 20 drepper@redhat.com Defect in XSH getrlimit() (rdvk# 13) {ud-process-18} Sat, 19 Oct 2002 07:22:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC change line 18094 to: RLIMIT_STACK This is the maximum size of the initial thread's stack in bytes. [...] Proposed rationale text: It should be noted that RLIMIT_STACK applies "at least" to the stack of the initial thread in the process, and not to the sum of all the stacks in the process, as that would be very limiting unless the value is so big as to provide no value at all with a single thread. _____________________________________________________________________________ Page: 551 Line: 18094 Section: getrlimit() Problem: Defect code : 3. Clarification required The RLIMIT_STACK symbol and the associated limit is currently described as: This is the maximum size of a process stack, in bytes. The implementation does not automatically grow the stack beyond this limit. The problem is: which stack? In a multi-threaded application there are many stack. Are the sizes all added up (probably not), is each thread's stack limited, or does this only apply to the initial thread. Please clarify. Action: I would hope the resolution is that the limit is on the initial thread's stack size only. In this case change line 18094 to: RLIMIT_STACK This is the maximum size of the initial thread's stack in bytes. [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 21 drepper@redhat.com Defect in XSH getsockopt() (rdvk# 5) {ud-shall-1} Sat, 19 Oct 2002 08:21:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 560 Line: 18360 Section: getsockopt() Problem: Defect code : 1. Error The SO_LINGER description in setsockopt() has already been shall-ified, getsockopt is missing. Action: Change line 18360 to: SO_LINGER is set, the system shall block the calling thread during close() until it (Note that this change already assumes the process->thread change). _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 drepper@redhat.com Defect in XSH getsockopt() (rdvk# 11) {ud-process-19} Sat, 19 Oct 2002 07:28:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 560 Line: 18360 Section: getsockopt() Problem: Defect code : 1. Error The SO_LINGER description currently says: If SO_LINGER is set, the system blocks the process during close() until [...] It's not the entire process which is blocked, only the calling thread. Action: Change line 18360 to: SO_LINGER is set, the system blocks the calling thread during close() until it _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 drepper@redhat.com Defect in XSH getsockopt() (rdvk# 10) {ud-process-20} Sat, 19 Oct 2002 07:29:53 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 560 Line: 18364 Section: getsockopt() Problem: Defect code : 1. Error Followup to the other SO_LINGER/process problem. It'is also the calling thread which is allowed to continue immediately. Action: Change line 18364 to: calling thread to continue as quickly as possible. This option shall store a linger _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 joannaf@sun.com Defect in XSH isunordered (rdvk# 36) {jf-zal-isunordered1} Wed, 25 Sep 2002 15:23:58 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 645 Line: 21256 Section: isunordered Problem: Defect code : 1. Error The text on line 21256: "If x or y is NaN, 0 shall be returned." Is incorrect. If x is NaN, then isunordered() must return 1. Likewise if y is NaN, then isunordered() must return 1. The Application Usage section (lines 21265-21266) for isunordered() talks about the correct behavior: "For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true." This is taken from section 7.12.14 of ISO/IEC 9899:1999 Action: Change text on line 21256 from: "If x or y is NaN, 0 shall be returned." to "If x or y is NaN, 1 shall be returned." _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 drepper@redhat.com Defect in XSH nanosleep() (rdvk# 9) {ud-process-21} Sat, 19 Oct 2002 07:47:56 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 820 Line: 26720 Section: nanosleep() Problem: Defect code : 1. Error This is in the rationale. It says: It is common to suspend execution of a process for an interval in order to poll the status of a [...] There is no easy way to syspend the process. In this context this is perhaps misleading since only the calling thread is suspended. Action: Change beginning of line 26720 to: It is common to suspend execution of a thread for an interval [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 26 drepper@redhat.com Defect in XSH pthread_cond_timedwait() (rdvk# 1) {ud-cv-1} Thu, 22 Aug 2002 20:17:11 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept TC Notes below on decision: [Feedback from DB on AG mailing list: I know that we made some timer validation EINVAL errors optional because we didn't want to require validation in situations where the timer might be irrelevant. That is, when the function can succeed immediately, it's silly to have to validate the time and fail because it was bad. While this might apply to select() and some others, I can't see how it could apply to pthread_cond_timedwait, since it has to wait and therefore has no possible success path (except, perhaps, for a spurious wake, which I think we can reasonably overlook) where it can ignore the timer. Anyway, I see no reason that the abstime EINVAL shouldn't be required, and it certainly shouldn't apply to pthread_cond_wait. I'm in favor of the change.] _____________________________________________________________________________ Page: 1033 Line: 32522 Section: pthread_cond_timedwait() Problem: Defect code : 1. Error The error section for pthread_cond_tiemdwait() and pthread_cond_wait() currently says: 32518 ERRORS 32519 The pthread_cond_timedwait( ) function shall fail if: 32520 [ETIMEDOUT] The time specified by abstime to pthread_cond_timedwait( ) has passed. 32521 The pthread_cond_timedwait( ) and pthread_cond_wait( ) functions may fail if: 32522 [EINVAL] The value specified by cond, mutex, or abstime is invalid. There are a number of things wrong: - pthread_cond_wait() has no abstime parameter; - the recognition of an invalid abstime parameter must not be optional. It isn't anywhere else. Action: Change the beginning of the ERRORS section above to: ERRORS The pthread_cond_timedwait( ) function shall fail if: [ETIMEDOUT] The time specified by abstime to pthread_cond_timedwait( ) has passed. [EINVAL] The value specified by abstime is invalid. The pthread_cond_timedwait( ) and pthread_cond_wait( ) functions may fail if: [EINVAL] The value specified by cond or mutex is invalid. I.e., create an [EINVAL] case in the "shall" section. _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 terekhov@de.ibm.com Defect in XSH pthread_detach() (rdvk# 43) {alt-detach-2002-11-06} Wed, 6 Nov 2002 18:46:23 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1049 Line: 32951 Section: pthread_detach() Problem: Defect code : 1. Error The specification says: 32951 The pthread_detach() function shall fail if: 32952 [EINVAL] The implementation has detected that the value specified by thread does not 32953 refer to a joinable thread. 32954 [ESRCH] No thread could be found corresponding to that specified by the given thread 32955 ID. "shall fail" is probably wrong here. Illustration: lnxmuell:/usr/terekhov # gcc -v Reading specs from /usr/lib/gcc-lib/s390-suse-linux/2.95.3/specs gcc version 2.95.3 20010315 (SuSE) lnxmuell:/usr/terekhov # rpm -q glibc glibc-2.2.2-26 lnxmuell:/usr/terekhov # gcc -pthread -o detach detach.c lnxmuell:/usr/terekhov # ldd ./detach libpthread.so.0 => /lib/libpthread.so.0 (0x40022000) libc.so.6 => /lib/libc.so.6 (0x40038000) /lib/ld.so.1 => /lib/ld.so.1 (0x40000000) lnxmuell:/usr/terekhov # ./detach 0 2nd detach: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./detach 1 2nd detach: 3 Guess what... : No such process lnxmuell:/usr/terekhov # ./detach 1 2nd detach: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./detach 0 2nd detach: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./detach 1 2nd detach: 3 Guess what... : No such process lnxmuell:/usr/terekhov # ./detach 1 2nd detach: 3 Guess what... : No such process lnxmuell:/usr/terekhov # ./detach 1 2nd detach: 3 Guess what... : No such process lnxmuell:/usr/terekhov # ./detach 100 2nd detach: 3 Guess what... : No such process lnxmuell:/usr/terekhov # ./detach 0 2nd detach: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./detach 1000000 2nd detach: 3 Guess what... : No such process lnxmuell:/usr/terekhov # ./detach 0 2nd detach: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # cat detach.c #include #include #include #include #include #include void* dummy( void* p ) { return 0; } int main(int argc, char *argv[]) { int status; pthread_t thid; assert( 2 == argc ); status = pthread_create( &thid, 0, &dummy, 0 ); assert( !status ); status = pthread_detach( thid ); assert( !status ); status = atoi(argv[1]); if ( status ) usleep( status ); status = pthread_detach( thid ); printf( "2nd detach: %d\n", status ); if ( status ) { errno = status; perror( "Guess what... " ); } return 0; } lnxmuell:/usr/terekhov # Action: Replace "shall fail" with "may fail": 32950 ERRORS 32951 The pthread_detach() function may fail if: 32952 [EINVAL] The implementation has detected that the value specified by thread does not 32953 refer to a joinable thread. 32954 [ESRCH] No thread could be found corresponding to that specified by the given thread 32955 ID. _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 terekhov@de.ibm.com Defect in XSH pthread_join() (rdvk# 41) {alt-join-2002-10-22} Tue, 22 Oct 2002 13:18:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Discussion over the terminology "the implementation has detected" It was agreed that there is some ambiguity and may need an interpretation Don proposed that for EINVAL we could change "shall fail"->"may fail" and remove "the implementation has detected" however ESRCH looks clear The consensus appears to be with this proposal _____________________________________________________________________________ Page: 1062 Line: 33322 Section: pthread_join() Problem: Defect code : 1. Error The specification says: 33322 The pthread_join() function shall fail if: 33323 [EINVAL] The implementation has detected that the value specified by thread does not 33324 refer to a joinable thread. 33325 [ESRCH] No thread could be found corresponding to that specified by the given thread 33326 ID. "shall fail" is probably wrong here. Illustration: lnxmuell:/usr/terekhov # gcc -v Reading specs from /usr/lib/gcc-lib/s390-suse-linux/2.95.3/specs gcc version 2.95.3 20010315 (SuSE) lnxmuell:/usr/terekhov # rpm -q glibc glibc-2.2.2-26 lnxmuell:/usr/terekhov # gcc -pthread -o join join.c lnxmuell:/usr/terekhov # ldd ./join libpthread.so.0 => /lib/libpthread.so.0 (0x40022000) libc.so.6 => /lib/libc.so.6 (0x40038000) /lib/ld.so.1 => /lib/ld.so.1 (0x40000000) lnxmuell:/usr/terekhov # ./join 2nd join: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # ./join 2nd join: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # ./join 2nd join: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./join 2nd join: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./join 2nd join: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # ./join 2nd join: 22 Guess what... : Invalid argument lnxmuell:/usr/terekhov # ./join 2nd join: 0 lnxmuell:/usr/terekhov # cat join.c #include #include #include #include void* dummy( void* p ) { return 0; } int main() { int status; pthread_t thid; status = pthread_create( &thid, 0, &dummy, 0 ); assert( !status ); status = pthread_join( thid, 0 ); assert( !status ); status = pthread_join( thid, 0 ); printf( "2nd join: %d\n", status ); if ( status ) { errno = status; perror( "Guess what... " ); } return 0; } lnxmuell:/usr/terekhov # Action: Replace "shall fail" with "may fail" [and remove 33327 -- see (***) below]: 33321 ERRORS 33322 The pthread_join() function may fail if: 33323 [EINVAL] The implementation has detected that the value specified by thread does not 33324 refer to a joinable thread. 33325 [ESRCH] No thread could be found corresponding to that specified by the given thread 33326 ID. (***) 33327 The pthread_join() function may fail if: 33328 [EDEADLK] A deadlock was detected or the value of thread specifies the calling thread. 33329 The pthread_join() function shall not return an error code of [EINTR]. _____________________________________________________________________________ OBJECTION Enhancement Request Number 29 terekhov@de.ibm.com Defect in XSH pthread_kill() (rdvk# 42) {alt-kill-2002-11-06} Wed, 6 Nov 2002 19:04:03 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The consensus was that it should stay the way it is , symettry with kill() was one of the reasons also the fact that if there is no thread and never has been a thread it must fail, having a may fail would mean that you could not count on even that behavior. _____________________________________________________________________________ Page: 1071 Line: 33597 Section: pthread_kill() Problem: Defect code : 1. Error The specification says: 33597 The pthread_kill() function shall fail if: 33598 [ESRCH] No thread could be found corresponding to that specified by the given thread 33599 ID. 33600 [EINVAL] The value of the sig argument is an invalid or unsupported signal number. I think that "shall fail" is wrong here too -- WRT [ESRCH], at least. The reasoning is as follows: http://groups.google.com/groups?selm=33D5F29E.3F54%40zko.dec.com (Subject: Re: [Q.] How to validate a thread ID) A call to pthread_kill with a signal number of 0 will check whether the thread ID is valid. If it's not valid, pthread_kill will return ESRCH, however, not -1. No pthread function, either in POSIX threads or in the obsolete "draft 7" API currently provided with AIX, will return -1. A thread ID is "valid" from the time it's created (sometime within the scope of the call to pthread_create that starts it) until it has terminated and been detached (either via the detachstate attribute having been set to PTHREAD_CREATE_DETACHED or by a successful call to either pthread_detach or pthread_join). There's no prohibition against using any function (except pthread_detach and pthread_join) on a thread that's detached. The catch is that you must ensure that the detached thread can't have terminated. Although pthread_kill, unlike most functions operating on a thread ID, is required to detect an invalid thread ID, the system is allowed to "recycle" a thread ID immediately upon termination of a detached thread -- so you might be checking the wrong thread. There isn't necessarily any good use for pthread_kill(,0). It's there mostly just because it mirrors the behavior of kill(,0). You can't use it to verify whether a detached thread has terminated unless you already know it CANNOT have terminated (because the thread ID may have been recycled), and you can't really use it for joinable threads, either. The ID is valid until it's been joined/detached, even if it's terminated, so the pthread_kill won't fail; and, as Patrick says, you presumably can know whether you've joined with the thread already. (And if you can't you're still in trouble since a successful return from pthread_join detaches the thread and allows the ID to be recycled.) So the documented, supported, and fully portable behavior of pthread_kill(,0) is absolutely useless except as a curiosity. 22057 In secure implementations, a process may be restricted from sending a signal to a process having 22058 a different security label. In order to prevent the existence or nonexistence of a process from 22059 being used as a covert channel, such processes should appear nonexistent to the sender; that is, 22060 [ESRCH] should be returned, rather than [EPERM], if pid refers only to such processes. 22061 Existing implementations vary on the result of a kill() with pid indicating an inactive process (a 22062 terminated process that has not been waited for by its parent). Some indicate success on such a 22063 call (subject to permission checking), while others give an error of [ESRCH]. Since the definition 22064 of process lifetime in this volume of IEEE Std 1003.1-2001 covers inactive processes, the 22065 [ESRCH] error as described is inappropriate in this case. In particular, this means that an 22066 application cannot have a parent process check for termination of a particular child with kill(). 22067 (Usually this is done with the null signal; this can be done reliably with waitpid().) ..... 32001 The pthread_cancel() function may fail if: ^^^^^^^^ 32002 [ESRCH] No thread could be found corresponding to that specified by the given thread 32003 ID. ..... 33144 The pthread_getcpuclockid( ) function may fail if: ^^^^^^^^ 33145 [ESRCH] The value specified by thread_id does not refer to an existing thread. ..... 33206 The pthread_getschedparam() function may fail if: ^^^^^^^^ 33207 [ESRCH] The value specified by thread does not refer to an existing thread. 33208 The pthread_setschedparam() function may fail if: ^^^^^^^^ ..... 33219 [ESRCH] The value specified by thread does not refer to a existing thread. ..... 35346 The pthread_setschedprio() function may fail if: ^^^^^^^^ ..... 35353 [ESRCH] The value specified by thread does not refer to an existing thread. Action: Make [ESRCH] *OPTIONAL* -- "may fail". Well, I don't really care about [EINVAL] in the case of pthread_kill(), but please consider also the following [with respect to ESRCH-vs-EINVAL and pthread_t values]: http://groups.google.com/groups?selm=RkQt9.5%24Rr2.256121%40news.cpqcorp.net (Subject: Re: pthread_join() on detached/exited/garbage thread?) POSIX says it is an error to join a thread that's been joined or detached, so the program cannot do so. The implementation, however, is required to detect and report that error, and it fails to do so. The second pthread_join() in each case must fail with at least EINVAL. (It cannot succeed.) The second pthread_join() call MAY also fail with ESRCH, depending on where the implementation wakes joining threads during termination; timing between the first join, termination, and the second join; and how the implementation detects the error conditions. That is, the target thread shall have always been detached/joined at the time of the second pthread_join() call, and it cannot succeed. However, given the ambiguity in definition of thread termination and join, the target may either have completely terminated at the time of the second join (in which case an ESRCH is appropriate), or it may still "exist", in which case EINVAL would be appropriate. There's nothing wrong with returning EINVAL even when the thread no longer exists, presumably indicating that the pthread_t value HAD BEEN valid, where ESRCH would mean the implementation knew it had never been valid, or at least cannot determine whether it might have been valid. (A thread that doesn't exist clearly "isn't joinable", after all.) In any case, the second call to pthread_join() CANNOT succeed. I presume that you see varying results because the implementation allows a thread to remain "existing" after the return of pthread_join(), and it sometimes continues to exist until the second call to pthread_join(). My guess is that pthread_join() is treating EINVAL as an existence test, and failing to distinguish that the thread is not joinable when it hasn't yet terminated completely. Note to everyone else: Alexander has instigated discussion of several issues within the Open Group forum, one of which is tightening the definition of pthread_join() to require that it return only when the target thread has been fully terminated. If that discussion were to eventually lead to changes in the standard, there could be no variability in the outcome of the second call to pthread_join(). Such work need not necessarily tighten the distinction between EINVAL and ESRCH such that a pthread_t value representing a thread that no longer exists couldn't legitimately be considered either "not existing" or "not joinable", though it might. _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 drepper@redhat.com Defect in XSH pthread_sigmask() (rdvk# 24) {ud-process-7} Sat, 19 Oct 2002 06:23:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1135 Line: 35413 Section: pthread_sigmask() Problem: Defect code : 1. Error A few mentionings of the mystical "process signal mask" remain in the pthread_sigmask/sigprocmask description. In all cases the reference should be changed to "thread signal mask". Action: Change beginning of line 35413 to: thread's signal mask shall be unchanged; [...] Change line 35428 to: shall be set to indicate the error, and the thread signal mask shall be unchanged. Change the beginning of line 35438 to: When a thread's signal mask is changed [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 drepper@redhat.com Defect in XSH setsockopt() (rdvk# 4) {ud-process-24} Sat, 19 Oct 2002 08:38:45 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1313 Line: 4067 Section: setsockopt() Problem: Defect code : 1. Error Followup to the other SO_LINGER/process problem. It'is also the calling thread which is allowed to continue immediately. Action: Change line 40674 to: that allows the calling thread to continue as quickly as possible. This option _____________________________________________________________________________ OBJECTION Enhancement Request Number 32 drepper@redhat.com Defect in XSH setsockopt() (rdvk# 6) {ud-process-23} Sat, 19 Oct 2002 08:19:21 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1313 Line: 40671 Section: setsockopt() Problem: Defect code : 1. Error The SO_LINGER description currently says: If SO_LINGER is set, the system shall block the process during close() until [...] It's not the entire process which is blocked, only the calling thread. Action: Change line 40671 to: If SO_LINGER is set, the system shall block the calling thread during close() _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 drepper@redhat.com Defect in XSH sigaction() (rdvk# 3) {ud-process-25} Sat, 19 Oct 2002 08:43:21 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1338 Line: 41457 Section: sigaction() Problem: Defect code : 1. Error The description of sigaction() says the "process signal mask" is modified before a signal handler is invoked. There is no process signal mask. Action: Change line 41457 to: signals that shall be added to the thread's signal mask before the signal-catching function is _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 drepper@redhat.com Defect in XSH sigaction() (rdvk# 2) {ud-process-26} Sat, 19 Oct 2002 08:57:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1339 Line: 41501 Section: sigaction() Problem: Defect code : 1. Error In the SA_SIGINFO description it is referred to the process context as being represented in the ucontext_t object. That's a thread's context. Action: Change line 41501 to: receiving thread's context that was interrupted when the signal was _____________________________________________________________________________ OBJECTION Enhancement Request Number 35 drepper@redhat.com Defect in XSH sigaction() (rdvk# 33) {ud-process-27} Sat, 19 Oct 2002 09:00:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1340 Line: 41523 Section: sigaction() Problem: Defect code : 1. Error The SA_NODEFER description refers to the process signal mask. There is no such thing. Action: Change line 41523 to: SA_NODEFER If set and sig is caught, sig shall not be added to the thread's signal mask _____________________________________________________________________________ OBJECTION Enhancement Request Number 36 drepper@redhat.com Defect in XSH sigaction() (rdvk# 32) {ud-process-27} Sat, 19 Oct 2002 09:01:22 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1340 Line: 41525 Section: sigaction() Problem: Defect code : 1. Error The SA_NODEFER description refers to the process signal mask. There is no such thing. Action: Change line 41525 to: sig shall always be added to the thread's signal mask on entry to the _____________________________________________________________________________ OBJECTION Enhancement Request Number 37 drepper@redhat.com Defect in XSH sigaction() (rdvk# 28) {ud-process-28} Sat, 19 Oct 2002 09:04:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Make the change noted below in the request, also Line 41607 either changed end of sentence restored by the process -> restored by the thread or just "restored" (editors to choose) _____________________________________________________________________________ Page: 1342 Line: 41525 Section: sigaction() Problem: Defect code : 1. Error This is an app usage. The delivery of a signal only interrupts a thread, not the process. Therefore in line 41605 When the signal handler returns, the receiving process resumes execution at the point it was the thread resumes, not the process. Action: Change line 41605 to: When the signal handler returns, the receiving thread resumes execution at the point it was _____________________________________________________________________________ OBJECTION Enhancement Request Number 38 bmark@us.ibm.com Defect in XSH sigtimedwait() (rdvk# 35) {IBM-091300201} Fri, 13 Sep 2002 16:10:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Need to insert "should" since this was in the original Base document 42520 An implementation should only....... _____________________________________________________________________________ Page: 1371 Line: 42518 Section: sigtimedwait() Problem: Defect code : 1. Error While the wording is clear in the POSIX real time signals definition of the EINVAL return from sigtimedwait(): [EINVAL] The timeout arguement specified a tv_nsec value less than zero or greater than or equal to 1000 million. An implementation only checks for this error if no signal is pending in set and it is necessary to wait. I have a hard time accepting the stated requirement. It clearly REQUIRES the implementation to determine if any of the selected signals are already pending before we can validate an input parameter. This appears to add unnecessary overhead to the sigtimedwait() function, and generate confusion for application programmers. I.E., if I were to incorrectly fill out the timespec structure, I couldn't be sure that the system would report this mistake to me as I tested my program. Later and inconveniently, the program could fail. Action: Remove lines 42520-42521. _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 drepper@redhat.com Defect in XSH sleep() (rdvk# 14) {ud-process-31} Sat, 19 Oct 2002 09:28:50 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1382 Line: 42857 Section: sleep() Problem: Defect code : 1. Error sleep() doesn't suspend the process, only the calling thread. Action: Change line 42857 to: alarm() function to schedule a SIGALRM signal and then suspend the calling thread waiting for that _____________________________________________________________________________ OBJECTION Enhancement Request Number 40 wollman@lcs.mit.edu Defect in XSH sysconf() (rdvk# 37) {_SC_FILE_LOCKING} Fri, 20 Sep 2002 03:58:53 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Probable action once confirmed: Delete only the occurrences in XSH and XBD The text in XRAT on page 292 must stay Same thing for _POSIX_MULTI_PROCESS on 43530 _____________________________________________________________________________ Page: 1467 Line: 45341 Section: sysconf() Problem: Defect code : 1. Error The sysconf key _SC_FILE_LOCKING is defined to return the value of _POSIX_FILE_LOCKING, which is undefined. Action: Either delete the references at XSH line 45341 and XBD line 14438 (those are the only two I can find), or add a description to XBD before line 14059 setting out the value to which _POSIX_FILE_LOCKING shall be defined. _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 drepper@redhat.com Defect in XSH usleep() (rdvk# 12) {ud-process-32} Sat, 19 Oct 2002 09:45:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC change process to thread on 48179 mark this as non-reentrant, use the normal boiler _____________________________________________________________________________ Page: 1561 Line: 48179 Section: usleep() Problem: Defect code : 1. Error This one is similar to the sleep() problem. Again the implementation is not required to restore the signal mask (it says process, but it's the thread's signal mask). Whatever the outcome for sleep() is must be applied here as well. Action: Two alternatives: a) declare usleep() as unsafe in multi-threaded applications. b) remove the limiting clause in lines 48178ff: It is also unspecified whether the SIGALRM signal is blocked, unless the process' signal mask is restored as part of the environment. _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 drepper@redhat.com Defect in XSH write() (rdvk# 7) {ud-process-33} Sat, 19 Oct 2002 09:56:05 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1653 Line: 50949 Section: write() Problem: Defect code : 1. Error This is in rationale. write() doesn't block the process. Otherwise, the process may block; Action: Change the beginning of line 50949 to: Otherwise, the calling thread may block; _____________________________________________________________________________ OBJECTION Enhancement Request Number 43 drepper@redhat.com Defect in XSH read() (rdvk# 8) {ud-process-22} Sat, 19 Oct 2002 08:01:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1692 Line: 36335 Section: read() Problem: Defect code : 1. Error There EAGAIN error description says: [...] and the process would be delayed. It's not the process which would get delayed, but the calling thread. Action: Change beginning of line 36335 to: [EAGAIN] The O_NONBLOCK flag is set for the file descriptor and the calling thread would be _____________________________________________________________________________ EDITORIAL Enhancement Request Number 44 david@djwhome.demon.co.uk Defect in XSH seteuid (rdvk# 44) {djw/1} Tue, 3 Dec 2002 16:29:49 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 0 Line: 0 Section: seteuid Problem: Defect code : 1. Error In the EPERM error description for seteuid: reference is made to real group IDs and saved effective group IDs when, I believe, the intention was to refer to user IDs, as is done in the DESCRIPTION section. Action: Replace both occurrences of "group" by "user" in the ERRORS section. _____________________________________________________________________________ OBJECTION Enhancement Request Number 45 David.Butenhof@hp.com Defect in XSH exec (rdvk# 46) {drb.6.exec.threads} Tue, 12 Nov 2002 13:22:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC The initial thread of the new process shall inherit at least the following attributes from the calling thread: * Signal mask (see sigprocmask() and pthread_sigmask()) * Pending signal (see sigpending()) _____________________________________________________________________________ Page: 297 Line: 9654 Section: exec Problem: Defect code : 1. Error A bulleted list on this page provides a list of attributes that the "new process" created by exec() shall inherit from "the calling process image". The two items "Process signal mask (see sigprocmask())" and "Pending signal (see sigpending())" do not belong in this list, as they do not refer to attributes of a process but rather to attributes of individual threads. Action: Remove these two items from the list. A second list could be constructed of attributes inherited from the calling thread, as such: The initial thread of the new process shall inherit at least the following attributes from the calling thread: * Signal mask (see sigprocmask() and pthread_sigmask()) * Pending signal (see sigpending()) Alternately, as many of the attributes inherited are already described outside this one list, the thread inheritance could be described in a separate paragraph either immediately following the list (before the current paragraph at line 9660 beginning "All other process attributes"), or prior to the list, as such: The initial thread in the new process shall inherit the signal mask and pending signals from the thread that called exec(). (See sigprocmask(), pthread_sigmask(), and sigpending().) _____________________________________________________________________________ OBJECTION Enhancement Request Number 46 David.Butenhof@hp.com Defect in XSH exec (rdvk# 45) {drb.6.exec.threads.2} Tue, 12 Nov 2002 13:33:54 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Replace the paragraph with the following: "All other process attributes defined in the volume of IEEE Std 1003.1-2001 shall be inherited in the new process image from the old process image. All other thread attributes defined in this volume of IEEE Std 1003.1-2001 shall be inherited in the initial thread in the new process image from the calling thread in the old process image. The inheritance of process or thread attributes not defined by this volume of IEEE Std 1003.1-2001 is implementation-defined." _____________________________________________________________________________ Page: 297 Line: 9660 Section: exec Problem: Defect code : 2. Omission The "catchall" paragraph (lines 9660 - 9662) does not account for the fact that some attributes once attached to the process are now attached to individual threads within the process: "All other process attributes defined in this volume of IEEE Std 1003.1-2001 shall be the same in the new and old process images. The inheritance of process attributes not defined by this volume of IEEE Std 1003.1-2001 is implementation-defined." On general principles, this should be adapted to account for any thread attributes that might be omitted in more specific text. Action: Replace the paragraph with the following: "All other process and thread attributes defined in this volume of IEEE Std 1003.1-2001 shall be set in the initial thread and process in the new process image as visible to the thread that called the exec function in the old process image. The inheritance of process or thread attributes not defined by this volume of IEEE Std 1003.1-2001 is implementation-defined." _____________________________________________________________________________ OBJECTION Enhancement Request Number 47 jan@Eng.Sun.COM Defect in XSH mq_getattr() (rdvk# 47) {jan-4191477} Tue, 14 Jan 2003 23:34:13 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 783 Line: 25660-25661 Section: mq_getattr() Problem: Defect code : 3. Clarification required The errors section for mq_getattr() currently requires that the function return -1 and set errno to EBADF if mqdes is not a vaild message queue descriptor. The message queue descriptor is of type mqd_t and the standard does not specify this type defintion. An implementation could define this type to be an interger type or a pointer type. If the latter then any random pointer value could be passed as the message queue descriptor to mq_getattr(). This could happen if a programming error resulting in mq_getattr() being called without mq_open() being called first. This error condition is akin to readdir() being called without opendir() being called first. The standard does not require that readdir() detect this condition, merely, that if detected, -1 is returned and that errno be set to EBADF. The wording for mq_getattr() should be changed to match readdir() because the situations are analogous, see proposed solution. Action: Request that the follow change be made XSH, P783, L25660 from: The mq_getattr() function shall fail if: to: The mq_getattr() function may fail if: _____________________________________________________________________________ objection Enhancement Request Number 48 joannaf@sun.com Defect in XSH gmtime_r() (rdvk# 51) {sunw-jf03-rk-1} Tue, 28 Jan 2003 12:37:42 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC (note AJ checked the TC1 page to verify the change below) Change XSH text lines 18970-18972 from "Upon successful completion, gmtime_r() shall return the address of the structure pointed to by the argument result. If an error is detected, or UTC is not available, gmtime_r() shall return a null pointer". to "Upon successful completion, gmtime_r() shall return the address of the structure pointed to by the argument result. If an error is detected, gmtime_r() shall return a null pointer and set errno to indicate the error". Note "or UTC is not available," was removed in XSH/TC1/D6/27. In the text changed by XSH/TC1/D6/27 [XSH ERN 27,28] change: 0657 "The gmtime() function shall fail if: 0658 [EOVERFLOW] The result cannot be represented." to "The gmtime() and gmtime_r() function shall fail if: [EOVERFLOW] The result cannot be represented." with "and gmtime_r()" shaded and margined marked TSF. _____________________________________________________________________________ Page: 577 Line: 18970-18972 Section: gmtime_r() Problem: Defect code : 2. Omission TC Change Number: XSH/TC1/D6/27 [XSH ERN 27,28] should apply to gmtime_r() as well as gmtime(). Changes are required to both XSH and the text approved in TC1. Action: Change XSH text lines 18970-18972 from "Upon successful completion, gmtime_r() shall return the address of the structure pointed to by the argument result. If an error is detected, or UTC is not available, gmtime_r() shall return a null pointer". to "Upon successful completion, gmtime_r() shall return the address of the structure pointed to by the argument result. If an error is detected, gmtime_r() shall return a null pointer and set errno to indicate the error". Note "or UTC is not available," was removed in XSH/TC1/D6/27. In the text changed by XSH/TC1/D6/27 [XSH ERN 27,28] change: 0657 "The gmtime() function shall fail if: 0658 [EOVERFLOW] The result cannot be represented." to "The gmtime() and gmtime_r() function shall fail if: [EOVERFLOW] The result cannot be represented." with "and gmtime_r()" shaded and margined marked TSF. The limitations of shading and margin markings may mean the above change to TC1 text to be impossible editorially. If that is so then just a seperate paragraph for gmtime_r should be added to Errors section: In XSH at line 18974 replace the line with: "The gmtime_r() function shall fail if: [EOVERFLOW] The result cannot be represented." with the text shaded and margined marked TSF. _____________________________________________________________________________ objection Enhancement Request Number 49 joannaf@sun.com Defect in XSH localtime_r() (rdvk# 50) {sunw-jf03-rk-2} Tue, 28 Jan 2003 12:48:42 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC (aj verified action) Change XSH text lines 23038-23039 from "Upon successful completion, localtime_r() shall return a pointer to the structure pointed to by the argument." to "Upon successful completion, localtime_r() shall return a pointer to the structure pointed to by the argument. If an error is detected, localtime_r() shall return a null pointer and set errno to indicate the error". In the text changed by XSH/TC1/D6/32 [XSH ERN 35] change: 0708 "The localtime() function shall fail if: 0709 [EOVERFLOW] The result cannot be represented." to "The localtime() and localtime_r() function shall fail if: [EOVERFLOW] The result cannot be represented." with "and localtime _r()" shaded and margined marked TSF. _____________________________________________________________________________ Page: 699 Line: 23038-23039 Section: localtime_r() Problem: Defect code : 2. Omission TC Change Number: XSH/TC1/D6/32 [XSH ERN 35] should apply to localtime_r() as well as localtime(). Changes are required to both XSH and text approved in TC1. Action: Change XSH text lines 23038-23039 from "Upon successful completion, localtime_r() shall return a pointer to the structure pointed to by the argument." to "Upon successful completion, localtime_r() shall return a pointer to the structure pointed to by the argument. If an error is detected, localtime_r() shall return a null pointer and set errno to indicate the error". In the text changed by XSH/TC1/D6/32 [XSH ERN 35] change: 0708 "The localtime() function shall fail if: 0709 [EOVERFLOW] The result cannot be represented." to "The localtime() and localtime_r() function shall fail if: [EOVERFLOW] The result cannot be represented." with "and localtime _r()" shaded and margined marked TSF. Note the limitations of shading and margin markings may require the above change to TC1 to be impossible editorially. If that is so then just a seperate paragraph for localtime_r should be added to Errors section: At line 23041 replace the line with: "The localtime_r() function shall fail if: [EOVERFLOW] The result cannot be represented." with the text shaded and margined marked TSF. _____________________________________________________________________________ objection Enhancement Request Number 50 joannaf@sun.com Defect in XSH mktime() (rdvk# 49) {sunw-jf03-rk-3} Tue, 28 Jan 2003 12:57:10 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC to: "The mktime() function shall return the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 [CX] and may set errno to indicate the error.[/CX]." Add to the ERRORS section(Shaded and marked with the CX margin code): "The mktime() function may fail if: [EOVERFLOW] The result cannot be represented." _____________________________________________________________________________ Page: 765 Line: 24996-25001 Section: mktime() Problem: Defect code : 2. Omission mktime()can now produce an error with a 64-bit time_t and a 32-bit tm_year for the same reasons gmtime() and localtime() can. Reference: TC Change Number: XSH/TC1/D6/27 [XSH ERN 27,28] TC Change Number: XSH/TC1/D6/32 [XSH ERN 35] Action: Change XSH text at lines 24996-25001 from: "The mktime() function shall return the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1." to: "The mktime() function shall return the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 [CX] and set errno to indicate the error.[/CX]." Add to the ERRORS section(Shaded and marked with the CX margin code): "The mktime() function shall fail if: [EOVERFLOW] The result cannot be represented." _____________________________________________________________________________ objection Enhancement Request Number 51 joannaf@sun.com Defect in XSH sysconf (rdvk# 48) {sunw-jf03-ld1} Tue, 28 Jan 2003 14:19:32 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_40 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1467 Line: 45341 Section: sysconf Problem: Defect code : 1. Error Subprofiling remnant _POSIX_FILE_LOCKING was missed when other IEEE Std 1003.13 subprofiling options were removed from normative text. All references should be removed. For reference see XRAT page 292 (Profile option): POSIX_FILE_LOCKING: Thread-Safe Stdio Locking flockfile (),ftrylockfile (),funlockfile(), getc_unlocked(),getchar_unlocked(),putc_unlocked(), Action: In XSH in the table for sysconf() on page 1467 line 45341 remove the _POSIX_FILE_LOCKING table entry. In XBD in on page 407 line 14438 remove _SC_FILE_LOCKING. _____________________________________________________________________________ objection Enhancement Request Number 52 drepper@redhat.com umask() omission (rdvk# 52) {ud.jan30} Thu, 30 Jan 2003 10:20:21 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1548 Line: 47755 Section: umask() Problem: A umask() call is defined to effect the creation mask used in open(), creat(), mkdir, and mkfifo(). This leaves out the XSI function mknod() which falls into the same category. In fact, mkfifo() is probably implemented in terms of mknod() on most systems. mknod() should be added to the list. Action: Replace line 47755 with The process file mode creation mask is used during open(), creat(), mkdir(), mkfifo(), and mknod() to turn where "and mknod()" is XSI shaded. Also, mknod() should be added to the SEE ALSO section in line 47779. _____________________________________________________________________________ OBJECTION Enhancement Request Number 53 joannaf@sun.com Defect in XSH makecontext (rdvk# 59) {sunw-jf03-dc-1} Fri, 14 Feb 2003 15:16:58 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 279 Line: 23931-23932 Section: makecontext Problem: Defect code : 1. Error With the incorporation of ISO/IEC 9899:1999 (C99) into this specification the makecontext() synopsis (XSH6, P279 L23931-23932) has been modified to make it strictly C99 conforming. The 1st paragraph of the description of makecontext() (XSH6, P729, L23937-23940) says that the arguments following argc in the makecontext() call are passed to func(). But, the "void (*func)(void)" in the function prototype on XSH6, P729, L23931-23932 does not allow any arguments to be passed to func(). Therefore, the standard conflicts with itself except in the case when argc is zero. In practice, func() is called by various applications with an arbitrary number of arguments (including zero) of varying types. Specifying func() as "void (*func)(int, ...)" would break all existing applications that currently use makecontext(), but it is the only way in ISO/IEC 9899:1999 (C99) to specify that func() takes one or more arguments of varying types. Furthermore, this would require that func() take at least one argument (invalidating the example shown on XSH6, P729-730, L23957-23991). C99 (subclause 6.11.6) specifies that the use of function declarators with empty parentheses is an obsolescent feature. Therefore, using the function prototype (as in XSH5, P493): void makecontext(ucontext_t *ucp, void (*func)(), int argc,...); is making use of an obsolescent feature of C99. Therefore, a strictly conforming POSIX application can't use this form and is why it changed in XSH6. There is no way in C99 to specify a non-obsolescent function prototype indicating that a function will be called with an arbitrary number (including zero) of arguments of arbitrary types (including integers, pointers to data, pointers to functions, and composite types). Therefore to continue to use the void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...); form it needs to be marked obsolescent. Replacing makecontext() with a bunch of C99 compatible functions handing various numbers and types of arguments will force all existing uses of makecontext() to be rewritten for little or no gain. There are very few applications today that use the *context() routines. Those that do use them are almost always using them to implement co-routines. By going back to the XSH5 specification for makecontext(), existing applications will continue to work, although they won't be able to be classified as strictly conforming applications. We (standards developers) are stuck between a rock and a hard place because there is no way in C99 (without using obsolescent behavior) to specify functionality that was standard, strictly conforming behavior in XSH5 using the 1990 C Standard. Threads can be used to implement the functionality provided by *context(), but is more complex to use. We believe that the pain of inventing new C99 compatible interfaces that describe what can be done with the XSH5 functions and then converting applications to use them would cause more pain than just converting applications that use them to use threads instead. (And, they can work on this effort until the next revision of the POSIX standards is approved.) Action: Change the makecontext() function prototype in XSH6 page 729 on lines 23931-23932 from: void makecontext(ucontext_t *ucp, void (*func)(void), int argc, ...); to: void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...); Mark getcontext() in XSH6 page 489, makecontext() in XSH6 page 729, swapcontext() in XSH6 page 1460, and in XBD6 page 396 obsolescent. Add Application Usage in XSH6 page 730 at line 23993 and in XSH6 page 489 after line 16116 saying: "The obsolescent functions getcontext(), makecontext() and swapcontext() can be replaced using POSIX threads functions." Add rationale to makecontext() in XSH6 page 730 line 23995 saying: "With the incorporation of ISO/IEC 9899:1999 (C99) into this specification it was found that C99 (subclause 6.11.6) specifies that the use of function declarators with empty parentheses is an obsolescent feature. Therefore, using the function prototype: void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...); is making use of an obsolescent feature of C99. Therefore, a strictly conforming POSIX application can't use this form. Therefore, use of this getcontext(), makecontext() and swapcontext() is marked obsolescent. There is no way in C99 to specify a non-obsolescent function prototype indicating that a function will be called with an arbitrary number (including zero) of arguments of arbitrary types (including integers, pointers to data, pointers to functions, and composite types). Replacing makecontext() with a number of C99 compatible functions handing various numbers and types of arguments would have force all existing uses of makecontext() to be rewritten for little or no gain. There are very few applications today that use the *context() routines. Those that do use them are almost always using them to implement co-routines. By maintaining the XSH5 specification for makecontext(), existing applications will continue to work, although they won't be able to be classified as strictly conforming applications. There is no way in C99 (without using obsolescent behavior) to specify functionality that was standard, strictly conforming behavior in XSH5 using the 1990 C Standard. Threads can be used to implement the functionality provided by makecontext(), getcontext() and swapcontext() but it is more complex to use. It was felt inventing new C99 compatible interfaces that describe what can be done with the XSH5 functions and then converting applications to use them would cause more difficulty than just converting applications that use them to use threads instead." _____________________________________________________________________________ OBJECTION Enhancement Request Number 54 joannaf@sun.com Defect in XSH iconv (rdvk# 61) {sunw-jf03-ld4} Tue, 18 Feb 2003 16:30:05 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: It was felt that an explicit decision had been made in the standard _____________________________________________________________________________ Page: 587 Line: 19272 Section: iconv Problem: Defect code : 1. Error There was a known descrepency in SUSv2 between the iconv.h header and the interface page for iconv(). The interface page defined the second argument as const char ** while the header page defined the second argument as char **. In interpretations on this it was noted as a Grey area in the Specification and that the second argument is "const char **" and not "char **". See interpretation PIN5.009 (http://www.opengroup.org/interps/xsh5/interps/pin/PIN5.009.html) See interpretation PIN4.029 (http://www.opengroup.org/interps/vsx/interps/pin/PIN4.029.html) SUSv3 has been changed so that interface page was change to match the header page so the second argument is "char **". This is also mentioned in E R N report Austin/50r1 (http://www.opengroup.org/austin/docs/austin_50r1.txt) where the change that the header page should have been made to match the interface page and define the second argument as "const char ** was rejected in ERN Number 316 due to a Base Working group ruling (vwg/071/061994) Looking up vwg/071/061994 in the base resolution document http://www.opengroup.org/docsrv/TGbase/BaseFeb96/interps/VWG93-001.txt shows the folowing: X/OPEN RESOLUTION: The synopsis on the iconv() manual page is in error and the synopsis on the page is correct. A future revision of XSH4 shall revise the prototype for iconv() as follows: Replace the argument type on the iconv() arguments in the synopsis with that specified on the function prototype in the header. For conformance to the current version of XSH4 either prototype is allowed. Test suite status: (iv) It is our belief that this resolution is in error and that as mentined in the above referenced interpretations the second argument is "const char **" and not "char **". This argument is not modified by the iconv() interface and for consistancy with other interfaces in SUSv3 that do not modify an argument this should be a const argument. Action: Change XSH6 page 587 line 19272 from: size_t iconv(iconv_t cd, char **restrict inbuf, to: size_t iconv(iconv_t cd, const char **restrict inbuf, and change XBD6 page 239 line 8386 from: size_t iconv(iconv_t, char **restrict, size_t *restrict, to: size_t iconv(iconv_t, const char **restrict, size_t *restrict, _____________________________________________________________________________ OBJECTION Enhancement Request Number 55 drepper@redhat.com Defect in XSH pthread_attr_getinheritsched() (rdvk# 56) {ptattr-1} Thu, 13 Feb 2003 08:12:42 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add to APPLICATION USAGE See Section 2.9.4 for further details on thread scheduling attributes and their default settings _____________________________________________________________________________ Page: 985 Line: 31346 Section: pthread_attr_getinheritsched() Problem: Defect code : 2. Omission The standard does not mention anywhere the default value of the value retrieved via pthread_attr_getinheritsched() after a call to pthread_attr_init(). The pthread_attr_getguardsize() man page does contain the appropriate information. I would guess the default value is PTHREAD_INHERIT_SCHED but I'm not sure at all. Action: Add new paragraph after line 31245. Add either The default value of the /inheritsched/ attribute is PTHREAD_INHERIT_SCHED or add The default value of the /inheritsched/ attribute is PTHREAD_EXPLICIT_SCHED _____________________________________________________________________________ OBJECTION Enhancement Request Number 56 drepper@redhat.com Defect in XSH pthread_attr_getschedpolicy() (rdvk# 55) {ptattr-2} Thu, 13 Feb 2003 09:10:59 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add to APPLICATION USAGE See Section 2.9.4 for further details on thread scheduling attributes and their default settings _____________________________________________________________________________ Page: 989 Line: 31443 Section: pthread_attr_getschedpolicy() Problem: Defect code : 2. Omission The standard does not mention anywhere the default value of the value retrieved via pthread_attr_getschedpolicy() after a call to pthread_attr_init(). The pthread_attr_getguardsize() man page does contain the appropriate information. I would guess the default value is SCHED_OTHER. Action: Add new paragraph after line 31442: The default value of the /schedpolicy/ attribute is SCHED_OTHER _____________________________________________________________________________ OBJECTION Enhancement Request Number 57 drepper@redhat.com Defect in XSH pthread_attr_getscope() (rdvk# 54) {ptattr-3} Thu, 13 Feb 2003 09:43:42 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add to APPLICATION USAGE See Section 2.9.4 for further details on thread scheduling attributes and their default settings _____________________________________________________________________________ Page: 991 Line: 31490 Section: pthread_attr_getscope() Problem: Defect code : 2. Omission The standard does not mention anywhere the default value of the value retrieved via pthread_attr_getscope() after a call to pthread_attr_init(). The pthread_attr_getguardsize() man page does contain the appropriate information. I don't know what the default value should be. If I would have to pick I'd chose PTHREAD_SCOPE_SYSTEM. Action: Add new paragraph after line 31490 either: The default value of the /contentionscope/ attribute is PTHREAD_SCOPE_SYSTEM or The default value of the /contentionscope/ attribute is PTHREAD_SCOPE_PROCESS _____________________________________________________________________________ OBJECTION Enhancement Request Number 58 drepper@redhat.com Defect in XSH pthread_cond_timedwait() (rdvk# 53) {ud-cond-1} Thu, 13 Feb 2003 23:04:50 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1032 Line: 32488 Section: pthread_cond_timedwait() Problem: Defect code : 1. Error The pthread_cond_timedwait() man page currently says: When the cancelability enable state of a thread is set to PTHREAD_CANCEL_DEFERRED, The problem is that PTHREAD_CANCEL_DEFERRED is no cancellation state value, but a cancellation type value. See pthread_setcancelstate() vs pthread_setcanceltype(). Action: Change line 32488 to type of a thread is set to PTHREAD_CANCEL_DEFERRED, a side effect of acting upon a (note the first word is now "type" instead of "state"). _____________________________________________________________________________ OBJECTION Enhancement Request Number 59 drepper@redhat.com Defect in XSH pthread_mutex_lock() (rdvk# 58) {ud-mut1} Sat, 15 Feb 2003 19:35:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add to the RATIONALE Add as lead in to para 3 For example, on systems not supporting the XSI extended mutex types, Add at the end of the rationale: For further rationale on the XSI extended mutex types please see the Rationale Volume. _____________________________________________________________________________ Page: 1081 Line: 33977 Section: pthread_mutex_lock() Problem: Defect code : 1. Error The paragraph in lines 33977 to 33982 comes from another time before the existence of error-checking mutexes. It's confusing today since error checking mutexes are standardized and do exactly what is here proposed the user should do. Action: Remove the whole paragraph. _____________________________________________________________________________ OBJECTION Enhancement Request Number 60 drepper@redhat.com Defect in XSH pthread_mutex_timedlock() (rdvk# 57) {ud-tpi1} Sat, 15 Feb 2003 21:47:11 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1084 Line: 34038 Section: pthread_mutex_timedlock() Problem: Defect code : 2. Omission The paragraph in lines 34038 to 34041 describes behavior which only applies if the TPI option is supported. The pthread_mutexattr_getprotocol man page has the functionality appropriately shaded but this is missing here. This is no loss or addition of a requirement. Action: Shade the whole paragraph and mark it wit TPI. _____________________________________________________________________________ OBJECTION Enhancement Request Number 61 joannaf@sun.com Defect in XSH sysconf (rdvk# 62) {sunw-jf03-jf1} Tue, 18 Feb 2003 10:45:05 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1468 Line: 45402 Section: sysconf Problem: Defect code : 1. Error _POSIX2_C_VERSION was removed by P1003.1a/P1003.2b and should disappear completely aligning with XBD6, Page 414, Line 14743. It cannot be required to be understood by sysconf() with no definition of what it means. It was used to specify the version of the C functions defined in POSIX.2-1992. There are no C functions specified in the XCU volume of SUSv3. We believe the following should have been deleted as part of the merge of P1003.1a and P1003.2b into the AGR: XBD6, Page 407, Line 14405 XSH6, Page 1468, Line 45390 XSH6, Page 1469, Lines 45452-45459 Had POSIX.1a and POSIX.2b completed independently of the revision, it could have been argued that this value could have identified that the POSIX.2 functions were now available in POSIX.1, but an updated value of POSIX_VERSION corresonding to the approval of P1003.1a would have done exactly the same thing. Action: Remove the following lines: XBD6, Page 407, Line 14405 XSH6, Page 1468, Line 45390 XSH6, Page 1469, Lines 45452-45459 _____________________________________________________________________________ OBJECTION Enhancement Request Number 62 joannaf@sun.com Defect in XSH sysconf (rdvk# 60) {sunw-jf03-ld3} Mon, 17 Feb 2003 14:56:18 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1469 Line: 45434 Section: sysconf Problem: Defect code : 1. Error We believe there is an issue with the description of _XOPEN_XCU_VERSION in SUSv3 and its usefulness for future product standards used for the creation of brands. In XPG3, XPG4, SUS, and SUSv2 (as well as with POSIX.1 and POSIX.2), it was possible to mix and match .1 and .2 implementations. (you could choose to implement XSH5 and XCU3 for instance, and get brands for XSH5 conformance without getting a brand for XCU5 conformance.) This made sense since POSIX.1 and POSIX.2 were separate standards. With SUSv3, we have a single standard that covers functions and utilities. In SUSv3 it seems that the description of _XOPEN_XCU_VERSION and what it should be set to is missing in the SUSv3 description. It's in the previous description of SUSv2 (XSH5 page 1195). The reason for the removing of _XOPEN_XCU_VERSION is documented in bwg2001-006 and covers the rationale as mentioned above (ie there is now only one standard that covers functions and utilities). We believe bwg2001-006 has not been fully applied to SUSv3 as there are other occurences of _XOPEN_XCU_VERSION in sysconf() and that these should also be removed as it can't be required to be understood by sysconf() with no definition of what it means. See: XBD page 409 (_SC_XOPEN_XCU_VERSION unistd.h definition) XSH page 1469 (_XOPEN_XCU_VERSION and _SC_XOPEN_XCU_VERSION in sysconf table) XSH page 1665 (index for _SC_XOPEN_XCU_VERSION and _XOPEN_XCU_VERSION) Action: Remove XBD page 409 line 14520 Remove XSH page 1469 line 45434 _____________________________________________________________________________ OBJECTION Enhancement Request Number 63 david.butenhof@hp.com Defect in XSH exec (rdvk# 63) {drb.7.exec.threads} Tue, 25 Feb 2003 15:55:00 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As below with the following change: from: {The pthread_t value returned by pthread_self() in the initial thread in the new process image is unspecified.}[THR] to: the thread id of the initial thread in the new process image is unspecified.}[THR] _____________________________________________________________________________ Page: 295-297 Line: 9574-9665 Section: exec Problem: Defect code : 1. Error The description of actions taken in response to a call to the exec() family of functions does not properly account for threads. Several actions have already been taken to improve this situation, including the recent ERNs 9, 45, and 46. However, these do not comprise a complete solution, and this aardvark strives to resolve some additional problems. ERN 46 added "catch all" text for "other thread attributes", along the lines of what had already existed for "other process attributes". However, there are some "other thread attributes" that require special behavior. 1. There are some we want NOT to be inherited, and 2. there are others we don't want to REQUIRE be inherited though there's no reason they need to be changed. In the former category, for example (the one that started all this), we don't want to require that the initial thread in the new process inherit the stack (or even the stacksize attribute) from the calling thread. In the second category would be the thread ID (pthread_t) value. While there's no particular reason the initial thread in the new process image CAN'T retain the ID of the calling thread (they're only meaningful within a process, and the values aren't specified), we certainly don't want to require that it must. Some of these are stated, or at least implied, elsewhere in the standard, but they ought to appear here. Action: [Note: sections in {...}[THR] are shaded and marked THR.] p 295, line 9574: replace The state of the floating-point environment in the new process image shall be set to the default. with The state of the floating-point environment in the new process image {or in the initial thread of the new process image}[THR] shall be set to the default. p 295, lines 9587-9588: replace After a successful call to any of the exec functions, any functions previously registered by atexit() are no longer registered. with After a successful call to any of the exec functions, any functions previously registered by atexit() {or pthread_atfork()}[THR] are no longer registered. p 296, lines 9612-9614: replace {For the SCHED_FIFO and SCHED_RR scheduling policies, the policy and priority settings shall not be changed by a call to an exec function. For other scheduling policies, the policy and priority settings on exec are implementation-defined.}[PS] with When the calling process image does not use the SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC scheduling policies, the scheduling policy and parameters of the new process image and the initial thread in that new process image are implementation defined. {When the calling process image uses the SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC scheduling policies, the process policy and scheduling parameter settings shall not be changed by a call to an exec function.}[PS] {The initial thread in the new process image shall inherit the process scheduling policy and parameters. It shall have the default system contention scope, but shall inherit its allocation domain from the calling process image.}[TPS] [Note: the scheduling inheritance I expect may be controversial. In particular there is room for discussion about how threaded process should inherit scheduling attributes. I believe that contention scope should be set to the (implementation defined) default because that makes the exec-ed process (and all processes are exec-ed!) work as I think most people expect. However, I think allocation domain (e.g., processor/RAD binding) ought to be inherited as it enables commonly implemented commands like 'runon' which must by definition affect not only themselves but the child processes they fork/exec. I added SCHED_SPORADIC to the special list only because I see no reason that it ought to have been omitted, and in consequence widened "priority" to "scheduling parameters".] Add following line 9638 (before the list that begins "The new process shall inherit at least..."): {The pthread_t value returned by pthread_self() in the initial thread in the new process image is unspecified.}[THR] >>>>> the thread id of the initial thread in the new process image is unspecified.}[THR] <<<<< {The size and location of the stack on which the initial thread in the new process image runs is unspecified.}[THR] [Associated rationale: we expect the initial thread to run on the "default process stack" but, in particular, it should not be constrained to any stack attributes inherited from the calling thread in the calling process image.] {The initial thread in the new process image shall have its cancellation type set to PTHREAD_CANCEL_DEFERRED and its cancellation state set to PTHREAD_CANCEL_ENABLED.}[THR] {The initial thread in the new process image shall have all thread-specific data values set to NULL and all thread-specific data keys shall be removed by the call to exec without running destructors.}[THR] {The initial thread in the new process image shall be joinable, as if created with the detachstate attribute set to PTHREAD_CREATE_JOINABLE.}[THR] p 297, line 9663-9665: replace A call to any exec function from a process with more than one thread shall result in all threads being terminated and the new executable image being loaded and executed. No destructor functions shall be called. with {A call to any exec function from a process with more than one thread shall result in all threads being terminated and the new executable image being loaded and executed. No destructor functions or cleanup handlers shall be called.}[THR] [Should this be shaded THR? It wasn't. On the one hand, it IS specific to threads and shading does no harm. On the other hand, the normative text cancels itself out without shading if there are no threads, since without the THR option there cannot be more than one thread.] _____________________________________________________________________________ OBJECTION Enhancement Request Number 64 drepper@redhat.com Defect in XSH pthread_cleanup_pop() (rdvk# 65) {ud-cleanup1} Fri, 21 Feb 2003 08:28:28 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add additional limitations. Add a new paragraph starting at line 32065: The effect of the use of 'return', 'break', 'continue', and 'goto' to prematurely leave a block described by a pair of pthread_cleanup_push() / pthread_cleanup_pop() functions calls is undefined. (there might be better wording) _____________________________________________________________________________ Page: 1020 Line: 32065 Section: pthread_cleanup_pop() Problem: Defect code : 1. Error The intend of the definition of the cleanup interfaces is to provide exception handling which can also be implemented using macros in plain C. The cleanup code is expected to run only when an exception occurs, which in case of pthreads is a call to pthread_exit() or the cancellation of the thread. Specifically a normal return does not constitute an exception. And very specifically, a return from the function started with pthread_create() costitutes an implicit call to pthread_exit() but the return itself does *not* represent such a call. But it is questionable whether any premature exit from a cancellation block is valid in the first case. Dave Butenhof wrote: >>>> Since we can't [...] require exceptions, the standard must prohibit 'return', 'break', 'continue', and 'goto' [...] <<<<< This is clearly a requirement unless exceptions are mandatory which is not acceptable (at this point in time at list). Action: Add additional limitations. Add a new paragraph starting at line 32065: The effect of the use of 'return', 'break', 'continue', and 'goto' to prematurely leave a block described by a pair of pthread_cleanup_push() / pthread_cleanup_pop() functions calls in undefined. _____________________________________________________________________________ COMMENT Enhancement Request Number 65 terekhov@de.ibm.com Defect in XSH pthread_mutex_lock() (rdvk# 71) {alt-EDEADLK-2003-02-24} Mon, 24 Feb 2003 18:23:44 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Accept the suggestion and the following: pthread_mutex_timedlock(): Change 34058 [EDEADLK] The current thread already owns the mutex. to 34058 [EDEADLK] A deadlock condition was detected or the current thread already owns the mutex. pthread_rwlock_rdlock(): Change 34811 [EDEADLK] The current thread already owns the read-write lock for writing. to 34811 [EDEADLK] A deadlock condition was detected or the current thread already owns the read-write lock for writing. pthread_rwlock_timedrdlock(): Change 34877 [EDEADLK] The calling thread already holds a write lock on rwlock. to 34877 [EDEADLK] A deadlock condition was detected or the calling thread already holds a write lock on rwlock. pthread_rwlock_timedwrlock(): Change 34935 [EDEADLK] The calling thread already holds the rwlock. to 34935 [EDEADLK] A deadlock condition was detected or the calling thread already holds the rwlock. pthread_rwlock_wrlock(): Change 35001 [EDEADLK] The current thread already owns the read-write lock for writing or reading. to 35001 [EDEADLK] A deadlock condition was detected or the current thread already owns the read-write lock for writing or reading. pthread_spin_lock(): Change 35546 [EDEADLK] The calling thread already holds the lock. to 35546 [EDEADLK] A deadlock condition was detected or the calling thread already holds the lock. _____________________________________________________________________________ Page: 1081 Line: 33962 Section: pthread_mutex_lock() Problem: Defect code : 3. Clarification required This is in response the proposed action of the defect report "ud-mut1" which suggests the removal of the following non- normative text from the pthread_mutex_lock()'s "RATIONALE" section: For example, deadlocking on a double-lock is explicitly allowed behavior in order to avoid requiring more overhead in the basic mechanism than is absolutely necessary. (More "friendly" mutexes that detect deadlock or that allow multiple locking by the same thread are easily constructed by the user via the other mechanisms provided. For example, pthread_self() can be used to record mutex ownership.) Implementations might also choose to provide such extended features as options via special mutex attributes. It seems that the issue here is whether it would really be "friendly" [or rather: *conforming*; performance aside] for an implementation to provide a "circular wait dependency" deadlock detection feature "by default" [i.e. running a portable application that doesn't use any of non-standard "special mutex attributes"]. IMO: yes and the EDEADLK error code may be used to report *any* deadlock condition -- things beyond a simple "double lock" error too. Action: Change 33962 [EDEADLK] The current thread already owns the mutex. to 33962 [EDEADLK] A deadlock condition was detected or the current thread already owns the mutex. Please note that if accepted, this will probably require making similar changes to other pthread blocking calls as well. _____________________________________________________________________________ OBJECTION Enhancement Request Number 66 drepper@redhat.com Defect in XSH sem_close() (rdvk# 64) {ud-sem1} Tue, 25 Feb 2003 00:51:39 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1243 Line: 38686 Section: sem_close() Problem: Defect code : 1. Error The specification for sem_close currently requires that EINVAL is returned for invalid descriptors. This should be just in all the other cases of functions which take descriptors a "may fail". Action: Change line 38686 to: The /sem_close()/ function may fail if: _____________________________________________________________________________ OBJECTION Enhancement Request Number 67 drepper@redhat.com Defect in XSH sem_destroy() (rdvk# 70) {ud-sem2} Tue, 25 Feb 2003 01:15:52 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1244 Line: 38723 Section: sem_destroy() Problem: Defect code : 1. Error The specification for sem_destroy currently requires that EINVAL is returned for invalid descriptors. This should be just in all the other cases of functions which take descriptors a "may fail". Action: Change line 38723 to: The /sem_destroy()/ function may fail if: and remove line 38725. _____________________________________________________________________________ OBJECTION Enhancement Request Number 68 drepper@redhat.com Defect in XSH sem_destroy() (rdvk# 69) {ud-sem3} Tue, 25 Feb 2003 01:17:13 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1245 Line: 38764 Section: sem_destroy() Problem: Defect code : 1. Error The specification for sem_getvalue currently requires that EINVAL is returned for invalid descriptors. This should be just in all the other cases of functions which take descriptors a "may fail". Action: Change line 38764 to: The /sem_getvalue()/ function may fail if: _____________________________________________________________________________ OBJECTION Enhancement Request Number 69 drepper@redhat.com Defect in XSH sem_post() (rdvk# 68) {ud-sem4} Tue, 25 Feb 2003 01:18:34 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1251 Line: 38962 Section: sem_post() Problem: Defect code : 1. Error The specification for sem_post currently requires that EINVAL is returned for invalid descriptors. This should be just in all the other cases of functions which take descriptors a "may fail". Action: Change line 38962 to: The /sem_post()/ function may fail if: _____________________________________________________________________________ OBJECTION Enhancement Request Number 70 drepper@redhat.com Defect in XSH sem_timedwait() (rdvk# 67) {ud-sem5} Tue, 25 Feb 2003 01:20:09 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1253 Line: 39017 Section: sem_timedwait() Problem: Defect code : 1. Error The specification for sem_timedwait currently requires that EINVAL is returned for invalid descriptors. This should be just in all the other cases of functions which take descriptors a "may fail". Action: Move line 39017 after line 39021. _____________________________________________________________________________ OBJECTION Enhancement Request Number 71 drepper@redhat.com Defect in XSH sem_trywait() (rdvk# 66) {ud-sem6} Tue, 25 Feb 2003 01:21:23 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1255 Line: 39068 Section: sem_trywait() Problem: Defect code : 1. Error The specification for sem_trywait and sem_wait currently requires that EINVAL is returned for invalid descriptors. This should be just in all the other cases of functions which take descriptors a "may fail". Action: Move line 39068 after line 39069. _____________________________________________________________________________ OBJECTION Enhancement Request Number 72 drepper@redhat.com Defect in XSH mmap() (rdvk# 72) {ud-mmap} Sat, 1 Mar 2003 00:41:07 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 771 Line: 25203 Section: mmap() Problem: Defect code : 1. Error This has probably been brought up before but I couldn't find anything in the standard or rationale. The standard currently does not say what has to happen if len==0. When using the len parameter in the description the interval [pa,pa+len) mentioned but if you fill in 0 for len you get [pa,pa) which is invalid. There is also no error value defined for it even though clearly no mapping can happen. Some implementations do not return an error but a subsequent munmap() with the address returned by mmap() will fail. I would suggest to explicitly de