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 describe the behavior of len == 0. The most logical possibility would be to require returning an error. Action: Add a new paragraph, perhaps after line 25202: If /len/ is zero /mmap()/ shall fail and no mapping shall be established. Add after line 25321: [EINVAL] The value of /len/ is zero. _____________________________________________________________________________ COMMENT Enhancement Request Number 73 gwc@opengroup.org Defect in XSH nftw (rdvk# 73) [gwc nftw example] Fri, 28 Feb 2003 12:10:57 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Change "to a maximum of 5 levels deep" to "using a maximum of 5 file descriptors". Global change of the argument "depth" in the parameter list (and text) to fd_limit , and in the example on line 26953 _____________________________________________________________________________ Page: 828 Line: 26942 Section: nftw Problem: Defect code : 1. Error The nftw EXAMPLE section states: The following example walks the /tmp directory and its subdirectories, calling the nftw() function for every directory entry, to a maximum of 5 levels deep. However, the spec does not require that passing depth=5 limits the depth of the walk, only that a maximum of 5 file descriptors can be used. Action: Change "to a maximum of 5 levels deep" to "and using a maximum of 5 file descriptors". _____________________________________________________________________________ OBJECTION Enhancement Request Number 74 drepper@redhat.com Defect in XSH timer_delete() (rdvk# 74) {ud-timer-1} Mon, 24 Mar 2003 08:23:37 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1517 Line: 46859 Section: timer_delete() Problem: Defect code : 1. Error The standard curently requires that timer_delete() recognizes invalid parameters. Just as for all other kinds of handles this should be optional here. Action: Replace line 46859 with: The /timer_delete()/ function may fail if: _____________________________________________________________________________ OBJECTION Enhancement Request Number 75 drepper@redhat.com Defect in XSH timer_getoverrun() (rdvk# 75) {ud-timer-2} Mon, 24 Mar 2003 08:25:58 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1519 Line: 46939 Section: timer_getoverrun() Problem: Defect code : 1. Error The standard curently requires that timer_getoverrun(), timer_gettime(), and timer_settime() recognizes invalid parameters. Just as for all other kinds of handles this should be optional here. Action: Replace line 46939 with: The timer_getoverrun(), timer_gettime(), and timer_settime() functions may fail if: _____________________________________________________________________________ OBJECTION Enhancement Request Number 76 drepper@redhat.com Defect in XSH Threads (rdvk# 76) {ud-cancel-1} Sat, 19 Apr 2003 18:01:59 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add to the section, "A cancellation point may also occur when a thread is executing the following functions:" in appropriate places. getaddrinfo, getnameinfo, strerror_r posix_openpt sync gethostid fmtmsg wordexp getopt [with footnote if opterr is nonzero] pathconf,fpathconf link, symlink stat,lstat,fstat access tzset,localtime,localtime_r, mktime,strftime,wcsftime,ctime, ctime_r,asctime,asctime_r _____________________________________________________________________________ Page: 56 Line: 2277 Section: Threads Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The list of potential cancellation points misses a few entries. The ones I have so far identified are these: getaddrinfo getnameinfo strerror_r The first should be added since functions like gethostbyname() etc are in the list. getaddrinfo() and getnameinfo() will likely use the same backend functionality, none of which gets by without opening some file or socket and reading from it. sterror_r() should be added because strerror() is in the list. Returning internationalized strings require this. Action: Add getaddrinfo, getnameinfo, and strerror_r to the list in appropriate places. ______________________________________________________________________________ COMMENT Enhancement Request Number 77 terekhov@de.ibm.com Defect in XSH 2.9.5.3 Cleanup Handlers (rdvk# 77) {alt-2.9.5.3-2003-04-04} Fri, 4 Apr 2003 15:50:45 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the proposal as is below, in the next revision consider the section title change The action is covered by two other ERNS and they are being considered independently, also there is now an action on Dave B, to produce text for 2.9.5.3 which may cover this. (marked back open as there is a proposal to delete text before the link to the two other ERNS) The ERN items describe three problems: 1. While POSIX cleanup handlers are explicitly defined to apply both to delivery of a cancellation request and a call to pthread_exit(), some of the descriptive text refers only to "cancel" or "cancellation", omitting pthread_exit(). This is an inconsistency in the existing standard, and clearly a textual omission the correction of which does not in any way change the INTENT of the working group. 2. Right now, the standard says that "cancellation is disabled" before invoking the cleanup handlers and that it remains disabled "until the last cancellation cleanup handler returns". It was never the intent of the working group that cancellation be re-enabled prior to calling thread-specific data destructor routines, yet the standard would appear to require that. I think it unlikely that anyone implemented this "incorrectly as specified", and in any case we should fix it. (And even if some implementation is broken, its unlikely and entirely unreasonable that any application could would actually depend on having a destructor routine cancelled.) 3. Alexander would like to see a more formal and complete description of both the cancelability STATE and TYPE during the execution of cleanup handlers. This would be a new requirement, since technically an implementation might meet the current terms of the specification by other means. Still, it seems reasonable and is the way most implementations probably work already. There's nothing in the descriptions either of pthread_cancel() or pthread_exit() that's wrong; nor anything that need to be fixed or added, contrary to the obvious implications of ERNs 81 and 82. Rather, the root of the problems, and the solution, lies in the text of section 2.9.5.3 as suggested by ERN 77. The current text of 2.9.5.3 is: 2.9.5.3 Thread Cancellation Cleanup Handlers Each thread maintains a list of cancellation cleanup handlers. The programmer uses the pthread_cleanup_push( ) and pthread_cleanup_pop( ) functions to place routines on and remove routines from this list. When a cancellation request is acted upon, the routines in the list are invoked one by one in LIFO sequence; that is, the last routine pushed onto the list (Last In) is the first to be invoked (First Out). The thread invokes the cancellation cleanup handler with cancellation disabled until the last cancellation cleanup handler returns. When the cancellation cleanup handler for a scope is invoked, the storage for that scope remains valid. If the last cancellation cleanup handler returns, thread execution is terminated and a status of PTHREAD_CANCELED is made available to any threads joining with the target. The symbolic constant PTHREAD_CANCELED expands to a constant expression of type (void *) whose value matches no pointer to an object in memory nor the value NULL. The cancellation cleanup handlers are also invoked when the thread calls pthread_exit(). A side effect of acting upon a cancellation request while in a condition variable wait is that the mutex is re-acquired before calling the first cancellation cleanup handler. In addition, the thread is no longer considered to be waiting for the condition and the thread shall not have consumed any pending condition signals on the condition. A cancellation cleanup handler cannot exit via longjmp() or siglongjmp(). Here's my proposed replacement: 2.9.5.3 Thread Cancellation Cleanup Handlers Each thread maintains a list of cancellation cleanup handlers. The programmer uses the pthread_cleanup_push( ) and pthread_cleanup_pop( ) functions to place routines on and remove routines from this list. When a cancellation request is acted upon, or when a thread calls pthread_exit(), the the thread first disables cancellation by setting its cancelability state to PTHREAD_CANCEL_DISABLE and its cancelability type to PTHREAD_CANCEL_DEFERRED. The cancelability state shall remain set to PTHREAD_CANCEL_DISABLE until the thread has terminated. The behavior is undefined if a cancellation cleanup handler or thread-specific data destructor routine changes the cancelability state to PTHREAD_CANCEL_ENABLE. The routines in the thread's list of cancellation cleanup handlers are invoked one by one in LIFO sequence; that is, the last routine pushed onto the list (Last In) is the first to be invoked (First Out). When the cancellation cleanup handler for a scope is invoked, the storage for that scope remains valid. If the last cancellation cleanup handler returns, thread-specific data destructors (if any) associated with thread-specific data keys for which the thread has non-NULL values will be run, in unspecified order, as described for pthread_key_create(). After all cancellation cleanup handlers and thread-specific data destructors have returned, thread execution is terminated. If the thread has terminated because of a call to pthread_exit(), the value_ptr argument is made available to any threads joining with the target. If the thread has terminated by acting on a cancellation request, a status of PTHREAD_CANCELED is made available to any threads joining with the target. The symbolic constant PTHREAD_CANCELED expands to a constant expression of type (void *) whose value matches no pointer to an object in memory nor the value NULL. A side effect of acting upon a cancellation request while in a condition variable wait is that the mutex is re-acquired before calling the first cancellation cleanup handler. In addition, the thread is no longer considered to be waiting for the condition and the thread shall not have consumed any pending condition signals on the condition. A cancellation cleanup handler cannot exit via longjmp() or siglongjmp(). I am strongly tempted to rename this section, since there's really not much to say in general about "cancellation cleanup handlers" without also talking about thread-specific data destructors and thread termination. For example, we could call it "Thread Termination". And, if we were to do this, it might be hard to resist the temptation to satisfy that long-outstanding work item to tighten up the definition of "thread termination" (which would now have at least a semi-formal working definition) to specify that the "joiner" it references will resume only after the terminating thread has completely ceased execution and use of any shared resources, including especially the stack. ;-) ______________________________________________________________________________ Page: 57 Line: 2342-2343 Section: 2.9.5.3 Problem: Defect code : 3. Clarification required The standard says: The thread invokes the cancelation cleanup handler with cancelation disabled until the last cancelation cleanup handler returns. To me, it doesn't say anything "specific enough" with respect to the VALUES of cancelability TYPE and STATE. Also, I don't quite follow "until the last cancellation cleanup handler returns" clause above. Surely, we do NOT want cancellation be enabled ("by default", I mean; enabling-it-for-something...catching-and-finalizing-pthread_cancel_e- exception aside for a moment ;-) ) in our TSD destructors (and no matter whether thread termination was caused by the cancel delivery or it is "just normal" termination -- either explicit or implicit call to pthread_exit()). Action: Remove completely 2342-2343 wording quoted above and apply the proposed changes (additions) that are stated in the defect reports "alt-pthread_cancel-2003-04-04" and "alt-pthread_exit-2003-04-04". _____________________________________________________________________________ OBJECTION Enhancement Request Number 78 drepper@redhat.com Defect in XSH lio_listio() (rdvk# 78) {ud-lio-1} Sat, 19 Apr 2003 18:29:23 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add at the end of line 22699: If the buffer pointed to by /list/ or the aiocb structures pointed to by the elements of the array /list/ become illegal addresses before all asynchronous I/O completed and, if necessary, the notification is sent, then the behavior is undefined. If the buffers pointed to by the /aio_buf/ member of the aiocb structure pointed to by the elements of the array /list/ become illegal addresses prior to the asynchronous I/O associated with that aiocb structure being completed, the behavior is undefined. _____________________________________________________________________________ Page: 686 Line: 22698 Section: lio_listio() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission While the aio_read/aio_write man pages explicitly mention that the result of the function is unspecified in case the aiocb variable becomes invalid (see XSH 110, lines 4077f) this is not spelled out for lio_listio. Moreoever, nothing is said about the array itself. It is clearly required that the aiocb structs remain valid, as for aio_read/aio_write and it should be spelled out, if not to avoid people drawing wrong conclusions from the asymmetry to aio_read/aio_write. The array passed in should probably be handled the same. Action: Add at the end of line 22699: If the buffers pointed to by /list/, the buffers for the aiocb structures pointed to by the non-NULL elements of /list/, or the buffers pointed to by the aio_buf elements in the aiocb structures pointed to by the non-NULL elements of /list/ become illegal addresses before all asynchronous I/O completed, then the behavior is undefined. Alternatively the requirements can be relaxed a bit. It could be possible to allow the aiocb output/input buffer memory be invalid if the operation finished but the liio_listio() isn't finished yet. Then use something like this: If the buffers pointed to by /list/ or the buffers for the aiocb structures pointed to by the non-NULL elements of /list/ become illegal addresses prior to all asynchronous I/O being completed, the behavior is undefined. If the buffers of the aiocb structures pointed to by the non-NULL elements of /list/ become invalid prior to the completion of the asynchronous I/O associated with the aiocb structure, the behavior is undefined. _____________________________________________________________________________ OBJECTION Enhancement Request Number 79 drepper@redhat.com Defect in XSH lio_listio() (rdvk# 79) {ud-lio-2} Sat, 19 Apr 2003 18:38:41 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 687 Line: 22733 Section: lio_listio() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission If lio_listio() is called with LIO_NOWAIT and the sigevent structure specifies that the notification happens via a new thread (SIGEV_THREAD), the thread attributes in the sigevent structure are used. But the attributes are not really part of the structure, there is just a pointer included. What happens of sig->sigev_notify_attributes becomes an illegal address? There are two possibilities: 1- the lio_listio() implementation is required to make a copy of the structure before returning. 2. the user is required to keep the structure pointed to by sig->sigev_notify_attributes valid until the last asynchronous operation finished and the notification has been sent. Action: To implement the second possibility, add after line 22732: If /sig->sigev_notify/ is SIGEV_THREAD and /sig->sigev_notify_attributes/ is a non-NULL pointer and the block pointed to by this pointer becomes an illegal address prior to all asynchronous I/O being completed, then the behavior is undefined. _____________________________________________________________________________ COMMENT Enhancement Request Number 80 dragan@soliton.com Defect in XSH mq_receive/mq_timedreceive (rdvk# 80) {dc-mq-1} Tue, 22 Apr 2003 15:50:42 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The change is not needed , the group feels the current wording is correct. _____________________________________________________________________________ Page: 793 Line: 25999 Section: mq_receive/mq_timedreceive Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Function mq_receive() has the following declaration (XSH page 793, lines 25999-26000): ssize_t mq_receive(mqd_t mqdes, char *msg_ptr, size_t msg_len, unsigned *msg_prio); whereas mq_timedreceive() has the following one (lines 26004-26007) ssize_t mq_timedreceive(mqd_t mqdes, char *restrict msg_ptr, size_t msg_len, unsigned *restrict msg_prio, const struct timespec *restrict abs_timeout); (note restrict qualifier for both msg_ptr and msg_prio in mq_timedreceive) Change prototype of mq_receive() to ssize_t mq_receive(mqd_t mqdes, char *restrict msg_ptr, size_t msg_len, unsigned *restrict msg_prio); i.e. add restrict to it. On the same line, maybe change of char * to void* is also appropriate to all mq_ send and receive functions. The same change is needed in the entry for mqueue.h (XBD page 273) in line 9729. Action: In lines 25999-26000, change mq_receive prototype to ssize_t mq_receive(mqd_t mqdes, char *restrict msg_ptr, size_t msg_len, unsigned *restrict msg_prio); or even better to ssize_t mq_receive(mqd_t mqdes, void *restrict msg_ptr, size_t msg_len, unsigned *restrict msg_prio); Apply the same change to mqueue.h (XBD page 273) in line 9729. _______________________________________________________________________________ COMMENT Enhancement Request Number 81 terekhov@de.ibm.com Defect in XSH pthread_cancel (rdvk# 81) {alt-pthread_cancel-2003-04-04} Fri, 4 Apr 2003 15:53:45 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_77 Reject_____ Rationale for rejected or partial changes: See 82 ______________________________________________________________________________ Page: 1018 Line: 31994 Section: pthread_cancel Problem: Defect code : 2. Omission Please consider the following piece of code: .... int state; pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &state); if (PTHREAD_CANCEL_ENABLE == state) { pthread_setcancelstate(state, &state); pthread_cancel(pthread_self()); pthread_testcancel(); } .... -and- .... int state; pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &state); if (PTHREAD_CANCEL_ENABLE == state) { pthread_setcancelstate(state, &state); // Uh... //pthread_cancel(pthread_self()); //pthread_testcancel(); pthread_exit(PTHREAD_CANCELED); } .... I just want that the code along these lines would NOT cause any problems when executed in the scope of some cleanup handler or some TSD-destructor. I'm afraid that with the current wording, executing such code in the scope of some cleanup handler or some TSD-destructor MAY cause problems. I want more clarity with respect to the VALUES of cancelability TYPE and STATE set by the implementation prior to "cleanup-unwinding" and TSD-destruction. Action: Insert the following wording (or something like that) at 31994: Before cancellation cleanup handlers followed by thread-specific data destructor functions are executed, the thread's cancelability state shall be set to PTHREAD_CANCEL_DISABLE and thread's cancelability type shall be set to PTHREAD_CANCEL_DEFERRED. ______________________________________________________________________________ COMMENT Enhancement Request Number 82 terekhov@de.ibm.com Defect in XSH pthread_exit- thread termination (rdvk# 82) {alt-pthread_exit-2003-04-04} Fri, 4 Apr 2003 15:54:57 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_77 Reject_____ Rationale for rejected or partial changes: we could make a change to the front matter 2.9.5.3 rather than on the pages rather for 81 and 82 Dave B to take an action ______________________________________________________________________________ Page: 1052 Line: 33028,33036 Section: pthread_exit Problem: Defect code : 2. Omission Two problems. The first one is "the same thing" as with the pthread_cancel(). It's reported in "alt-pthread_cancel-2003-04-04" DR of mine. Please see that DR for details. The second one is that there really should be no restrictions on pthread_exit that don't apply to cancellation -- they're effectively the same : http://google.com/groups?threadm=3e8c8a0f%40usenet01.boi.hp.com (Subject: Re: cancellation during cleanup handler execution) sorry for a google reference, I just can't resist. Action: 1. Insert the following wording (or something like that) at 33028 (after "...unspecified order."): Before cancellation cleanup handlers followed by thread-specific data destructor functions are executed, the thread's cancelability state shall be set to PTHREAD_CANCEL_DISABLE and thread's cancelability type shall be set to PTHREAD_CANCEL_DEFERRED. 2. Insert the following wording (or something like that) at 33036 (after "...pthread_exit()"): or cancellation processing _____________________________________________________________________________ OBJECTION Enhancement Request Number 83 mstrbill@us.ibm.com Defect in XSH aio_read/aio_write (rdvk# 83) {wlt_vsrt-1} Tue, 29 Apr 2003 13:00:09 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC aio_read [EINVAL] The file offset value implied by aiocbp->aio_offset would be invalid, [PIO]aiocbp->aio_reqprio is not a valid value[/PIO], or aiocbp->aio_nbytes is an invalid value. aio_write [EINVAL] The file offset value implied by aiocbp->aio_offset would be invalid, [PIO]aiocbp->aio_reqprio is not a valid value[/PIO], or aiocbp->aio_nbytes is an invalid _____________________________________________________________________________ Page: 110 Line: 4080 Section: aio_read/aio_write Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The aio_read() and aio_write ERRORS section require an EINVAL for a invalid value of aiocbp->aio_reqprio even when _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING are not supported by the implementation. From SUSv3: from aio_read 4080 [EINVAL] The file offset value implied by aiocbp->aio_offset would be invalid, 4081 aiocbp->aio_reqprio is not a valid value, or aiocbp->aio_nbytes is an invalid 4082 value. from aio_write 4269 [EINVAL] The file offset value implied by aiocbp->aio_offset would be invalid, 4270 aiocbp->aio_reqprio is not a valid value, or aiocbp->aio_nbytes is an invalid 4271 value. Section 2.8.2 states the following: 1716 If _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING are defined, then 1717 asynchronous I/O is queued in priority order, with the priority of each asynchronous operation 1718 based on the current scheduling priority of the calling process. The aio_reqprio member can be 1719 used to lower (but not raise) the asynchronous I/O operation priority and is within the range 1720 zero through {AIO_PRIO_DELTA_MAX}, inclusive. Unless both _POSIX_PRIORITIZED_IO and 1721 _POSIX_PRIORITY_SCHEDULING are defined, the order of processing asynchronous I/O 1722 requests is unspecified. If _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING are not supported by the implementation, there is no reason for the value of aiocbp->aio_reqprio to be checked by aio_read()/aio_write(). And certainly the implementation has not defined valid values for aio_reqprio for these syscalls to check against. Action: In the ERRORS section for aio_read() and aio_write() add an additional EINVAL section for aio_reqprio with PIO margin legend and text shading. _____________________________________________________________________________ OBJECTION Enhancement Request Number 84 don.cragun@sun.com Defect in XSH localtime() (rdvk# 84) {dwc:localetime_r.1} Fri, 25 Apr 2003 16:44:05 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add a new paragraph following P702, L23181 with TSF and XSI shading: "If the reentrant version does not set tzname, it shall not set daylight and shall not set timezone." _____________________________________________________________________________ Page: 702 Line: 23181 Section: localtime() Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The localtime() function on systems supporting the X/Open System Interfaces Extension (XSI) is required to set the external variables daylight and timezone (as well as the external variable tzname) since it is required to act as though it calls tzset(). On systems supporting XSI, the daylight, timezone, and tzname variables should all be set to provide information for the same timezone. The description of localetime_r() explicitly states that localtime_r() is not required to set tzname, but does not mention daylight nor timezone. This allows the value of tzname to be completely unrelated to daylight and timezone after a call to localtime_r(). Was this really intended? Action: Add a new paragraph following P702, L23181 with TSF and XSI shading: "If the reentrant version does not set tzname, it shall not set daylight and shall not set tzname." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 85 don.cragun@sun.com Defect in XSH localtime() (rdvk# 85) {dwc:localetime_r.2} Fri, 25 Apr 2003 16:50:47 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 704 Line: 23245 Section: localtime() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The description of localtime() on P702, L23164-23165 refers to tzset(), but tzset() is not listed in the SEE ALSO section. Action: Add "tzset(), " on P704, L23245 before "utime(),". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 86 don.cragun@sun.com Defect in XSH mktime() (rdvk# 86) {dwc:localetime_r.3} Fri, 25 Apr 2003 16:58:04 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 769 Line: 25185 Section: mktime() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The description of mktime() on P768, L25139 refers to tzset(), but tzset() is not listed in the SEE ALSO section. Action: Add "tzset(), " on P769, L25185 before "utime(),". _____________________________________________________________________________ COMMENT Enhancement Request Number 87 bmark@us.ibm.com Defect in XSH mq_open() (rdvk# 87) {IBM-050203-3} Fri, 2 May 2003 16:17:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Change the wording to: The permission bits of the message queue shall be set to the value of the mode argument except those set in the file mode creation mask of the process. When bits in mode other than the file permission bits are specified, the effect is unspecified. (consistency with shm_open/sem_open) _____________________________________________________________________________ Page: 790 Line: 25933 Section: mq_open() Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required For the O_CREAT mode of shm_open() and sem_open(), the file permission language is as follows: The permission bits of the semaphore are set to the value of the mode argument except those set in the file mode creation mask of the process For the O_CREAT mode of mq_open(), the languge is simply this: The file permission bits shall be set to the value of mode. So - mask applied for shm_open() and sem_open(), but not mq_open(). Is that intended or an oversight? Action: I know that these words are straight from 1003.1-1996, but is this meant to be inconsistent? _____________________________________________________________________________ OBJECTION Enhancement Request Number 88 bmark@us.ibm.com Defect in XSH open (rdvk# 88) {IBM-050203-2} Fri, 2 May 2003 16:08:11 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Submitter withdrawn. _____________________________________________________________________________ Page: 838 Line: 27275 Section: open Problem: Edition of Specification (Year): 2003 Defect code : 1. Error open(), shm_open(), and mq_open() all contain language similar to the following: Values for oflag are constructed by a bitwise-inclusive OR of flags from the following list, defined in . Applications shall specify exactly one of the first three values (file access modes) below in the value of oflag: O_RDONLY Open for reading only. O_WRONLY Open for writing only. O_RDWR Open for reading and writing. These modes are logically exclusive and therefore the idea of constructing oflag from a bitwise-inclusive or of the combination is nonsense. The section defining O_RDONLY, O_WRONLY, and O_RDWR does not seem to require that those values be bitwise-distinct, presumably because there is no logic in combining the values (you can't open something as both read-only and write-only, and the other option is explicitly defined). Action: I believe that the proper language for those interfaces should be something to the effect of: Values for oflag are from the following list, as defined in .... _____________________________________________________________________________ OBJECTION Enhancement Request Number 89 drepper@redhat.com Defect in XSH pthread_attr_getstack() (rdvk# 89) {ud-stackaddr} Thu, 1 May 2003 19:54:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: On Page: 58 Line: 2379 Section: Threads (2003 Ed.) On Page: 58 Line: 2380 Section: Threads (2001 Ed.) Insert new section: "2.9.8 Use of Application-Managed Thread Stacks An "application-managed thread stack" is a region of memory allocated by the application (for example, memory returned by the malloc() or mmap() functions) and designated as a stack through the act of passing an address related to that memory as the "stackaddr" argument to pthread_attr_setstackaddr() (obsolete) or by passing the address and size of the stack, respectively, as the stackaddr and stacksize arguments to pthread_attr_setstack(). Application-managed stacks allow the application to precisely control the placement and size of a stack. The application grants to the implementation permanent ownership of and control over the application-managed stack when the attributes object in which the stack or stackaddr attribute has been set is used, either by presenting that attributes object as the 'attr' argument in a call to pthread_create() that completes successfully, or by storing a pointer to the attributes object in the sigev_notify_attributes member of a 'struct sigevent' and passing that 'struct sigevent' to a function accepting such argument that completes successfully. The application may thereafter utilize the memory within the stack only within the normal context of stack usage within or properly synchronized with a thread that has been scheduled by the implementation with stack pointer value(s) that are within the range of that stack. In particular, the region of memory cannot be freed, nor can it be later specified as the stack for another thread. When specifying an attributes object with an application-managed stack through the sigev_notify_attributes member of a 'struct sigevent', the results are undefined if the requested signal is generated multiple times (as for a repeating timer). Until an attributes object in which the stack or stackaddr attribute has been set is used, the application retains ownership of and control over the memory allocated to the stack. It may free or reuse the memory as long as it either deletes the attributes object, or before using the attributes object replaces the stack by making an additional call to the same function (either pthread_attr_setstackaddr() or pthread_attr_setstack()) that was used originally to designate the stack. There is no mechanism to retract the reference to an application-managed stack by an existing attributes object. Once an attributes object with an application-managed stack has been used, that attributes object cannot be used again (by a subsequent call to pthread_create() or any function accepting a 'struct sigevent' with sigev_notify_attributes containing a pointer to the attributes object), without designating an unused application-managed stack by making an additional call to the function originally used to define the stack (pthread_attr_setstack() or pthread_attr_setstackaddr())." On Page: 996 Line: 31731 Section: pthread_attr_getstack (2003 Ed.) On Page: 993 Line: 31565 Section: pthread_attr_getstack (2001 Ed.) In the APPLICATION USAGE Add at the end: "After a successful call to pthread_attr_setstack(), the storage area specified by the stackaddr parameter is under the control of the implementation as described in Section 2.9.8." On Page: 998 Line: 31777 Section: pthread_attr_getstackaddr (2003 Ed.) On Page: 995 Line: 31611 Section: pthread_attr_getstackaddr (2003 Ed.) In the APPLICATION USAGE Add at the end: "After a successful call to pthread_attr_setstackaddr(), the storage area specified by the stackaddr parameter is under the control of the implementation as described in Section 2.9.8." In XRAT On Page: 177 Line: 7479 Section: B.2 Threads (2003 Ed.) On Page: 178 Line: 7442 Section: B.2 Threads (2003 Ed.) Insert new section before B.2.10 B.2.9.8 Use of Application-Managed Thread Stacks IEEE Std 1003.1-2001/Cor 2-200x, item XSH/TC2/Dx/x is applied, adding this new section. It was added to make it clear that the current standard does not allow an application to determine when a stack can be reclaimed. This may be addressed in a future revision. _____________________________________________________________________________ Page: 996 Line: 31706 Section: pthread_attr_getstack() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission This applies to the pthread_attr_setstackaddr() function as well but I don't file two bugs. Both pages can get the same change if necessary. The use of a user-specified stack for a thread has been identified as problematic in the past. Once a thread terminates, how to determine the thread stack is unused? pthread_join() doesn't guarantee that. I don't think this has been exactly specified since it's not generally possible. Anyway, a related problem is: what is the status of the stack before the thread is created? This is especially important with situations where the creation of the thread is not directly under the user's control (e.g., when SIGEV_THREAD is used for AIO or timers). One possible solution for the problem is to say that the stack is under the implementations control right after the pthread_attr_setstack() call until either a thread is created using the attribute and the thread terminated, or the attribute is destroyed before a thread is created. The latter phrase covers the AIO and timer case: if a the attribute is destroyed while the AIO request is still outstanding (or the timer is still running) the memory pointed to by the attribute becomes invalid which (according to ERN XSH 79) makes the AIO (and by extension timer) behavior unspecific. Action: Add after lines 31705: After a successful call of pthread_attr_setstack(), the storage area specified by the stackaddr parameter to pthread_setstack is under the control of the implementation. It must not be used before either the thread created with this attribute terminated or pthread_attr_destroy() has been called to destroy the attribute before a thread has been created using this attribute. For pthread_attr_setstackaddr() add after line 31759: After a successful call of pthread_attr_setstackaddr(), the storage area specified by the stackaddr parameter to pthread_setstack is under the control of the implementation. It must not be used before either the thread created with this attribute terminated or pthread_attr_destroy() has been called to destroy the attribute before a thread has been created using this attribute. _______________________________________________________________________________ EDITORIAL Enhancement Request Number 90 terekhov@de.ibm.com pthread_cond_wait -- wait on a condition (rdvk# 90) {alt-cond{timed}wait-2003-05-05} Mon, 5 May 2003 11:30:52 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC (tc2 d2) A/M Replace para 32652 - 32655 When a thread waits on a condition variable, having specified a particular mutex to either the pthread_cond_timedwait() or pthread_cond_wait() operation, a dynamic binding is formed between that mutex and condition variable that remains in effect as long as at least one thread is blocked on the condition variable. During this time, the effect of an attempt by any thread to wait on that condition variable using a different mutex is undefined. Once all waiting threads have been unblocked (as by the pthread_cond_broadcast() operation), the next wait operation on that condition variable shall form a new dynamic binding with the mutex specified by that wait operation. Even though the dynamic binding between condition variable and mutex may be removed or replaced between the time a thread is unblocked from a wait on the condition variable and the time that it returns to the caller or begins cancellation cleanup, the unblocked thread shall always re-acquire the mutex specified in the condition wait operation call from which it is returning. ______________________________________________________________________________ Page: 1036 Line: 32655 Section: pthread_cond_timedwait, Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard says: "The effect of using more than one mutex for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the same condition variable is undefined; that is, a condition variable becomes bound to a unique mutex when a thread waits on the condition variable, and this (dynamic) binding shall end when the wait returns." ^^^^^^^ I don't like/want to keep track of "returns"... given that I'm absolutely NOT required to keep track of "returns" if, instead of 'rebinding', I simply destroy the condvar (with some 'precautions') -- the standard says: "It shall be safe to destroy an initialized condition variable upon which no threads are currently blocked"; please see the pthread_cond_destroy() spec.). Actually, unless I am just missing and/or misunderstanding something, "returns", in the current wording, looks like a simple typo, so to speak. Action: Replace "when the wait returns" with "when all threads blocked on the condition variable are unblocked" (or something that). Alternative from DB: When a thread waits on a condition variable, having specified a particular mutex to either the pthread_cond_timedwait() or pthread_cond_wait() operation, a dynamic binding is formed between that mutex and condition variable that remains in effect as long as at least one thread is blocked on the condition variable. During this time, the effect of an attempt by any thread to wait on that condition variable using a different mutex is undefined. Once all waiting threads have been unblocked (as by the pthread_cond_broadcast() operation), the next wait operation on that condition variable shall form a new dynamic binding with the mutex specified by that wait operation. Even though the dynamic binding between condition variable and mutex may be removed or replaced between the time a thread is unblocked from a wait on the condition variable and the time that it returns to the caller or begins cancellation cleanup, the unblocked thread shall always re-acquire the mutex specified in the condition wait operation call from which it is returning. _______________________________________________________________________________ COMMENT Enhancement Request Number 91 terekhov@de.ibm.com Defect in XSH pthread_create -- thread creation (rdvk# 91) {alt-pthread_create-2003-05-02} Fri, 2 May 2003 17:05:07 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Interp This would imply a change in the standard, and quite a big one at that, which could break some implementations , not thought to be appropriate for a TC, possibly for the next revision, therefore this is on the interpretation track. The interp , the standard is what it says, in a future revision consider the following change: The additional wording is as follows: "The ID of the created thread shall be stored in the location referenced by thread before the newly created thread starts." (Note that the caller can get the ID available thru the return value and that the created thread can get the ID available thru pthread_self()) TC Add to APPLICATION USAGE (for the TC) "There is no requirement on the implementation that the ID of the created thread be available before the newly created thread starts executing. The calling thread can obtain the ID of the created thread through the return value of the pthread_create() function, and the newly created thread can obtain its ID by a call to pthread_self()." _______________________________________________________________________________ Page: 1050 Line: 33013 Section: pthread_create Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The standard doesn't specify when pthread_create() shall store the ID of the created thread in the location referenced by /thread/ with respect to thread creation/scheduling. Well, the "problem" here is that I simply got sick and tired pointing out that the ID written by pthread_create() may NOT be "visible" to the created thread; "4.10" rules aside for a moment. I hope that strengthening pthread_create() in this respect can be made through the next update (TC2). TIA. Action: Add "as if it was written by the calling thread prior to calling this function" (or something like that) to the statement: "Upon successful completion, /pthread_create/() shall store the ID of the created thread in the location referenced by /thread/". _____________________________________________________________________________ OBJECTION Enhancement Request Number 92 bmark@us.ibm.com Defect in XSH setlocale (rdvk# 92) {IBM-050203-1} Fri, 2 May 2003 16:02:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Ad an additional CX shaded piece of text as the 2nd last sentence to the DESCRIPTION in setlocale() [CX] Setting all of the categories of the locale of the process is similar to successively setting each individual category of the locale of the process, except that all error checking is done before any actions are performed. To set all the categories of the locale of the process, setlocale() is invoked as: setlocale(LC_ALL, ""); In this case, setlocale() first verifies that the values of all the environment variables it needs according to the precedence rules, described in the Base Definitions Volume of IEEE Std 1003.1-8, Chapter 8, Environment Variables, indicate supported locales. If the value of any of these environment-variable searches yields a locale that is not supported (and nonnull), the setlocale() function returns a null pointer and the locale of the process is not changed. If all environment variables name supported locales, setlocale() then proceeds as if it had been called for each category, using the appropriate value from the associated environment variable or from the implementation-defined default if there is no such value. [/CX] Earlier in the DESCRIPTION change from: "" Specifies an implementation-defined native environment. [CX] This corresponds to the value of the associated environment variables, LC_* and LANG ; see the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 7, Locale and the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 8, Environment Variables. [/CX] To: "" Specifies an implementation-defined native environment. [CX] The determination of the name of the new locale for the specified category depends on the value of the associated environment variables, LC_* and LANG ; see the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 7, Locale and the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 8, Environment Variables. [/CX] Add a SEE ALSO to Section 8.2 in XBD In XRAT Section 8.2 Internationalization Variables Change existing first paragraph to: "Utilities conforming to the Shell and Utilities volume of IEEE Std 1003.1-2001 and written in standard C can access the locale variables by issuing the following call: setlocale(LC_ALL, "") If this were omitted, the ISO C standard specifies that the C locale would be used." We need to prefix the text.... "If any of the environment variables are invalid, it makes sense to default to an implementation-defined, consistent locale environment....." With , "For the standard utilities..." and Add text before that paragraph with . "The DESCRIPTION of setlocale() requires that when setting all categories of a locale,that if the value of any of the environment-variable searches yields a locale that is not supported (and nonnull), the setlocale() function returns a null pointer and the locale of the process is unchanged." _____________________________________________________________________________ Page: 1299 Line: 40458 Section: setlocale Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required What happens if LC_ALL is unset, some LC_* env vars are set, but to an invalid locale, and a setlocale(LC_ALL,"") is done. setlocale states p1299, lines 40499: " "" - Specifies an implementation-defined native environment. This corresponds to the value of the associated environment variables, LC_* and LANG; see the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 7, Locale and the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 8, Environment Variables." >From XBD Chapter 7, locale (XBD p123, line 3952: "Applications can select the desired locale by invoking the setlocale() function (or equivalent) with the appropriate value. If the function is invoked with an empty string, such as: "setlocale(LC_ALL, "");" the value of the corresponding environment variable is used. If the environment variable is unset or is set to the empty string, the implementation shall set the appropriate environment as defined in Chapter 8 (on page 159)." XBD Chapter 8, states. (XBD 164, line 5719) "The environment variables LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, XSI LC_MONETARY, LC_NUMERIC, LC_TIME, and NLSPATH provide for the support of internationalized applications. The standard utilities shall make use of these environment variables as described in this section and the individual ENVIRONMENT VARIABLES sections for the utilities. If these variables specify locale categories that are not based upon the same underlying codeset, the results are unspecified." and (XBD 215, line 5760) "If the locale value is not recognized by the implementation, the behavior is unspecified. " "At runtime, these values are bound to a programs locale by calling the setlocale( ) function. " "Additional criteria for determining a valid locale name are implementation-defined." According to the above sections of text, when a setlocale(LC_*,"") is done when the corresponding LC_ category env var is set to a invalid locale, it is implementation defined what setlocale() does. It may choose to follow the precedence rules and return NULL And while it is not normative, in section A.8.2 of SUSV3, the spec writers believe that this would a appropriate action to take: "If any of the environment variables are invalid, it makes sense to default to an implementation-defined, consistent locale environment. It is more confusing for a user to have partial settings occur in case of a mistake." The reason we are asking for a clarification is that following the above reasoning results in test failures, which are rationalized as "The test results you are getting show that your setlocale() call is returning NULL, so you are not meeting the requirement that the locale settings are not changed when setlocale() returns NULL. You could perhaps argue from the "behavior is unspecified" statement that your setlocale() call should be allowed to return non-NULL (and change the locale settings to an implementation-defined default) in this case, but that seems to me to be a very dubious thing to do. If you want to change setlocale() to return non-NULL, and you are able to get an Austin Group interpretation which says this is allowed, then I will change the test so that it only checks the locale settings if setlocale() returned NULL." Action: Clarify the meaning of the standard. Is setlocale() required to return NULL and change nothing, or is the result implementation-defined as per the XBD? _____________________________________________________________________________ OBJECTION Enhancement Request Number 93 david.butenhof@hp.com Defect in XSH sigaction (rdvk# 93) {drb-sigaction-tc2} Fri, 25 Apr 2003 14:46:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept as marked Delete end of paragraph commencing after shaded text on 41691 _____________________________________________________________________________ Page: 1344 Line: 41691 Section: sigaction Problem: Edition of Specification (Year): 2003 Defect code : 1. Error (For those who'd prefer to use printed pre-TC1 documents, the original page is 1338 and the line number is 41453. The text is identical.) The standard says the following: If the SA_SIGINFO bit is cleared and the sa_handler field specifies a signal-catching function, or if the SA_SIGINFO bit is set, the sa_mask field identifies a set of signals that shall be added to the signal mask of the thread before the signal-catching function is invoked. If the sa_handler field specifies a signal-catching function, the sa_mask field identifies a set of signals that shall be added to the process' signal mask before the signal-catching function is invoked. The use of the word "process" has already been addressed in ERN 33, but in reviewing this section to answer a question recently, I observe that there are additional problems here. The intent is clearly that sa_mask specifies signals to be masked when a signal-catching function is called. The only purpose I can see for the distinction between whether or not SA_SIGINFO is set, is that one specifies the signal-catching function using different members of struct sigaction -- and that isn't specified here. Effectively, this text implies that a signal-catching function shall be invoked when SA_SIGINFO is set... even if there's no signal-catching function specified. Additionally, the final sentence is redundant, since sa_handler is used only when SA_SIGINFO is clear, and that case has already been covered. Action: I think what we actually want is this: If the SA_SIGINFO bit is cleared and the sa_handler field specifies a signal-catching function, or if the SA_SIGINFO bit is set and the sa_sigaction field specifies a signal-catching function, the sa_mask field identifies a set of signals that shall be added to the signal mask of the thread before the signal-catching function is invoked. Or, alternately, one might consider that this entire discussion is redundant with the paragraph on page 1346 (old 1340), line 41765 (41527): When a signal is caught by a signal-catching function installed by sigaction(), a new signal mask is calculated and installed for the duration of the signal-catching function (or until a call to either sigprocmask() or sigsuspend() is made). This mask is formed by taking the union of the currnet signal mask and the value of the sa_mask for the signal being delivered unless SA_NODEFER or SA_RESETHAND is set, and then including the signal being delivered. If and when the user's signal handler returns normally, the original signal mask is restored. We would lose nothing by removing the original quoted text on page 1344 entirely, as the page 1346 text is more complete (specifying how and when the temporary signal mask is removed as well as more fully describing how it is created). _____________________________________________________________________________ OBJECTION Enhancement Request Number 94 david.butenhof@hp.com Defect in XSH sigwait (rdvk# 94) {drb-sigwait-tc2} Fri, 25 Apr 2003 14:25:43 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 1380 Line: 42882 Section: sigwait Problem: Edition of Specification (Year): 2003 Defect code : 1. Error (For those who'd prefer to use printed pre-TC1 documents, the original page is 1374 and the line number is 42637. The text is identical.) The description of sigwait says "Which thread returns from sigwait() if more than a single thread is waiting is unspecified." This is correct only when the signal in question is generated for the process rather than for a specific thread. The common purpose of sigwait is to wait for "asynchronous" (process generated) signals, such as SIGINT, or SIGCHLD. Generally, there is no point in waiting for thread generated signals, such as SIGSEGV, because they cannot occur while the thread is waiting; they were not considered when writing the standard. However, pthread_kill() is an exception. It's conceivable (though perhaps a bit odd) that an application could be designed such that it might want to interrupt a particular sigwait() thread, for example using pthread_kill(tid,SIGUSR1). Technically, the standard currently specifies that a conforming implementation need not awaken thread "tid" in this case, but may instead awaken ANY thread currently blocked in sigwait with SIGUSR1 in its selection mask. This is unreasonable. Action: Revise this sentence as follows: "If more than a single thread is blocked in sigwait() for a signal when that signal is generated for the process, it is unspecified which of the waiting threads will return from sigwait(). If the signal is generated for a specific thread, as by pthread_kill(), only that thread shall return." _____________________________________________________________________________ OBJECTION Enhancement Request Number 95 drepper@redhat.com Defect in XSH timer_create() (rdvk# 95) {ud-timer-attr} Thu, 1 May 2003 18:55:27 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: After line 47034 add [shaded with marker TSA]: If evp->sigev_sigev_notify is SIGEV_THREAD and sev->sigev_notify_attributes is not NULL, if the attribute pointed to by sev->sigev_notify_attributes has a thread stack address specified by a call to pthread_attr_setstack() or pthread_attr_setstackaddr() the results are unspecified if the signal is generated more than once. App usage for timer_create(). If a timer is created which has evp->sigev_sigev_notify set to SIGEV_THREAD and the attribute pointed to by evp->sigev_notify_attributes has a thread stack address specified by a call to either pthread_attr_setstach() or pthread_attr_setstackaddr() the memory so dedicated as a thread stack can never be recovered. The reason for this is that the threads created in response to a timer expiration are created detached (or in an unspecified way if the thread attribute's /detachstate/ is PTHREAD_CREATE_JOINABLE). In neither case is it legal to call pthread_join(). But this makes it impossible to determine the lifetime of the created which which means the stack memory can never again be reused. For timer_settime(). Add after line 47217 (2003 edition): The /timer_settime()/ function may fail if: [EINVAL] The /it_internal/ member of /value/ is not zero and the timer was created with notification by creation of a new thread (sigev_sigev_notify was SIGEV_THREAD) and a fixed stack address has been set in the thread attribute pointed to by sigev_notify_attributes. Replace line 47052 (app usage) with: Using fixed stack addresses is problematic when timer expiration is signalled by the creation of a new thread. Since there is no guarantee that the thread created for one expiration is finished before the next expiration of the timer, it could happen that two threads use the same memory as stack at the same time. This is invalid and produces undefined results. _____________________________________________________________________________ Page: 1521 Line: 47035 Section: timer_create() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission It is possible for a timer to be created with the notification method set to SIGEV_THREAD. A new thread is created for every timer expiration. The so created thread need not return right away, it could theoretically run forever. The notification mechanism does not depend on reusing the thread. This is at least what I get from the missing requirements on the thread's behavior. If this is true there is a problem with the thread attributes passed in the struct sigevent structure to timer_create(). The attribute can be created with a specific thread, i.e., pthread_attr_setstack() or pthread_att_setstackaddr() have been called. This would make it impossible to create more than one thread with this attribute. Action: There are two possibilities: 1. Require the thread used for timer expiration notification to return before the next notification is sent (using the same thread). This requires that the user code doesn't call pthread_exit() which probably very problematic to introduce today. 2. Require that the thread attribute passed to timer_create() does not have a specific stack set (stack size is OK). Unless the former is really is what has been originally intended (in which case lots of work on clarification is needed) I suggest adding the following wording to the timer_create() man page: After line 47034 add [shaded with marker TSA]: If evp->sigev_sigev_notify is SIGEV_THREAD and sev->sigev_notify_attributes is not NULL, the attribute pointed to by sev->sigev_notify_attributes must not have a thread stack address specified by a call to pthread_attr_setstack() or pthread_attr_setstackaddr(). After line 47045 add: [EINVAL] The specified thread attribute is invalid. Maybe this should be an "may"-error. I have no problem requiring it. _____________________________________________________________________________ OBJECTION Enhancement Request Number 96 bjh21@netbsd.org Defect in XSH rename() (rdvk# 96) {bjh21-rename} Fri, 16 May 2003 18:16:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Concern that this is established behavior, if we were designing a new interface we could permit this but the existing interface must not change. _____________________________________________________________________________ Page: 1209 Line: 37639-37641 Section: rename() Problem: Edition of Specification (Year): 2001 Defect code : 1. Error rename() is currently required to do nothing and return success when its two arguments refer to the same file, even if they refer to different links to the same file. i.e., the sequence: link("a", "b"); rename("a", "b"); is required to leave "a" in existence. This seems to be generally regarded as silly (search for "rename" in subject lines in austin-group-l for previous discussions of the subject) and to have been an error in POSIX since the year dot. Because several implementations have carefully conformed with POSIX's past requirement, it would be unreasonable to mandate sensible behaviour now, but we can at least permit it. Action: Replace "same existing file" with "same existing directory entry", so the sentence reads: # If the argument and the argument resolve to the same # existing directory entry, rename() shall return successfully and # perform no action. page 1209 line 3761 section rename() Add to the end of the paragraph: # If the argument and the argument resolve to the same # existing file but not to the same directory entry, rename() may # return successfully and perform no action, or alternatively may # behave as described below. page 1211 line 37739 section rename() Replace "file" with "directory entry". page 1211 line 37740 section rename() Insert a new paragraph after this line: # The specification of the case where and refer to different # directory entries naming the same file is intended to permit # implementations to conform with earlier standards which required # rename() to succeed and perform no action in these circumstances. _____________________________________________________________________________ OBJECTION Enhancement Request Number 97 drepper@redhat.com Defect in XSH sem_open() (rdvk# 97) {ud-sem_open} Fri, 16 May 2003 22:11:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: Note some editorial cleanup needed _____________________________________________________________________________ Page: 1254 Line: 39115 Section: sem_open() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The sem_open() page currently states: >>>>>> If a process makes multiple successful calls to sem_open() with the same value for name, the same semaphore address shall be returned for each such successful call, provided that there have been no calls to sem_unlink() for this semaphore. <<<<<< In sem_close() we read: >>>>>> The sem_close() function shall deallocate (that is, make available for reuse by a subsequent sem_open() by this process) any system resources allocated by the system for use by this process for this semaphore. <<<<< Now, what should happen for this case: sem_t *s1 = sem_open ("/foo", ...); sem_close (s1); sem_t s2 = sem_open ("/foo", ...); According to the sem_open() documentation we must have s1 == s2. But according to the sem_close() documentation we must not keep any kind of information regarding the semaphore, all resources must be freed. While I could see that relaxing the wording in sem_close() is possible I think the problem is in sem_open(). Why should in the above case the above case the address be the same? I see the point in case the sem_close() doesn't happen and the first reference doesn't go away. But if no reference remains there should be no such requirement. Assume an implementation which uses mmap() to create the semaphore image in memory. There can be arbitrarily many function calls between sem_close() and the second sem_open() and the implementation would have to make sure the address space once allocated for s1 is not reused. And sem_close() has to unmap the mapping since otherwise this would create a resource leak. I think what the sem_open() specification should require is that the same address is returned unless sem_unlink() is used *and* there remains a reference to the semaphore object. Action: Add at the end of lines 39115 to 39117: [...] and at least one previous successful sem_open() call for this semaphore has not been matched with sem_close() call. Better wording welcome. _____________________________________________________________________________ OBJECTION Enhancement Request Number 98 drepper@redhat.com Defect in XSH umask() (rdvk# 98) {ud-umask2} Sat, 17 May 2003 09:04:08 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace line 48027 with The process file mode creation mask is used during open(), creat(), mkdir(), mkfifo(), mknod(), mq_open() and sem_open() to turn where "and sem_open()" is SEM shaded and mq_open shaded as MSG Also, mq_open and sem_open() should be added to the SEE ALSO section in line 48051. Need to work on sentence structure to accomodate shading _____________________________________________________________________________ Page: 1555 Line: 48027 Section: umask() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Another function which is influenced by the file create mask is missing from the list. Action: After applying XSH ERN 52: Replace line 48027 with The process file mode creation mask is used during open(), creat(), mkdir(), mkfifo(), mknod(), and sem_open() to turn where "and sem_open()" is SEM shaded. Also, sem_open() should be added to the SEE ALSO section in line 48051. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 99 ajosey@opengroup.org Defect in XSH 2.4.3 (rdvk# 99) {sockatmark} Tue, 27 May 2003 12:34:30 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 33 Line: 1337 Section: 2.4.3 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error When sockatmark was added in D7 we forgot to add it to the table in XSH 2.4.3 (the set of functions that shall either be reentrant or non-interruptable by signals and shall be async-signal-safe). Action: Add sockatmark() to the table in 2.4.3 _____________________________________________________________________________ COMMENT Enhancement Request Number 100 terekhov@de.ibm.com Defect in XSH pthread_setspecific (rdvk# 100) {alt-tsdset-2003-05-23} Fri, 23 May 2003 14:57:40 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1064 Line: 33451 Section: pthread_setspecific Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The standard says: "[ENOMEM] Insufficient memory exists to associate the value with the key." Now, please consider the following piece of code: #include // for std::bad_alloc, std::try_again aside for a moment #include struct no_cleanup { void operator()(void *) { // noop } }; template< typename T > struct deleter { void operator()(T * p) { delete p; } }; extern "C" typedef void (* c_TSD_dtor_t)(void *); template< typename T > c_TSD_dtor_t c_TSD_dtor(); template<> c_TSD_dtor_t c_TSD_dtor< no_cleanup >() { return 0; } extern "C" void c_deleter_for_int_ptr(void * p) { delete static_cast(p); } template<> c_TSD_dtor_t c_TSD_dtor< deleter< int > >() { return c_deleter_for_int_ptr; } /* ... other {needed} "c_deleter"-stuff ... */ template< typename T, typename cleanup > class thread_specific_ptr /* noncopyable [for now] */ { pthread_key_t m_key; public: thread_specific_ptr() throw(std::bad_alloc/*, std::try_again*/) { int status = pthread_key_create(&m_key, c_TSD_dtor< cleanup >()); // throw std::bad_alloc if status == ENOMEM // throw std::try_again if status == EAGAIN assert(!status); } ~thread_specific_ptr() throw() { int status = pthread_key_delete(m_key); assert(!status); } T * get() const throw() { return static_cast(pthread_getspecific(m_key)); } void set(T * p) const throw(std::bad_alloc) { int status = pthread_setspecific(m_key, p); // throw std::bad_alloc if status == ENOMEM assert(!status); } T * operator->() const throw() { return get(); } T & operator*() const throw() { return *get(); } T * release() throw() { T * p = get(); if (p) set(0); // only an idiot will throw std::bad_alloc here return p; } void reset(T * p /* "probably" != 0 */) throw(std::bad_alloc) { T * old_p = get(); if (old_p != p) { set(p); cleanup()(old_p); } } void reset() throw() { cleanup()(release()); } }; // Dear WG21 {co-}liaison/member, please: http://tinyurl.com/chl6 This smart pointer is been modeled {"not ready", yet} upon the std::auto_ptr and various other smart pointers coming via the C++ Library TR. The "problem" here is in the release() method: T * release() throw() { T * p = get(); if (p) set(0); // only an idiot will throw std::bad_alloc here return p; } I'd love to remove "if (p)" checking marked by a somewhat offending [sorry for that] comment above. The problem with T * release() throw() { T * p = get(); set(0); return p; } is that my reading of the standard [and a rather limited experience with "some" implementations] makes me think that it MIGHT "suddenly" die in the std::unexpected()... and THAT is Not Good, I believe. Action: Replace "...associate the value with the key." with "...associate the non-NULL value with the key." _____________________________________________________________________________ COMMENT Enhancement Request Number 101 terekhov@de.ibm.com Defect in XSH pthread_key_delete (rdvk# 101) {alt-tsdkey-2003-05-23} Fri, 23 May 2003 19:09:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The standard already requires what is being requested. No change required see pthread_key_create p1069 lines 33581 which says when you create a new key the value NULL is associated with the key. _____________________________________________________________________________ Page: 1073 Line: 33701-33710 Section: pthread_key_delete Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard says: "The pthread_key_delete() function shall delete a thread-specific data key previously returned by pthread_key_create(). The thread-specific data values associated with key need not be NULL at the time pthread_key_delete() is called. It is the responsibility of the application to free any application storage or perform any cleanup actions for data structures related to the deleted key or associated thread-specific data in any threads; this cleanup can be done either before or after pthread_key_delete() is called. Any attempt to use key following the call to pthread_key_delete() results in undefined behavior. The pthread_key_delete() function shall be callable from within destructor functions. No destructor functions shall be invoked by pthread_key_delete(). Any destructor function that may have been associated with key shall no longer be called upon thread exit." The problem here is the reuse of TSD keys without cleaning up the slots in all threads with non-NULL TSD values prior to the key destruction (it's simply "a bit expensive", so to speak): late and incompletely considered addition of pthread_key_delete broke the standard. It IS possible to implement the implications of the current standard, but it's messy and inefficient, and violates some principle tenets of the working group -- anyone who had proposed such a solution would have gone down in flames, fast. Well, we've got a "phoenix" technology here, so I'll give it a try. ;-) I agree that for keys with non-NULL destructors, applications should take responsibility for cleaning up the data and setting occupied slots to NULL prior to key destruction (as part of some application synchronization protocol tracking a shared key usage). However, I think that the situation is entirely different for the TSD keys without (with NULL) destructors. Please consider the following implementation of the DCSI [double-checked serialized initialization] "pattern": class thing { public: thing(/* ... */) : /* ... */ stuff_ptr(0) /* ... */ { /*...*/ } ~thing() { /* ... */ delete stuff_ptr.load(); /* ... */ } /* ... */ const stuff & stuff_instance(); /* ... */ private: /* ... */ mutex stuff_mtx; atomic stuff_ptr; /* ... */ }; const stuff & thing::stuff_instance() { // "lazy" one stuff * ptr; // hoist load barrier (with data dependency "hint") if (0 == (ptr = stuff_ptr.load_ddhlb())) { mutex::guard guard(stuff_mtx); if (0 == (ptr = stuff_ptr.load())) { ptr = new stuff(/*...*/); // sink store barrier stuff_ptr.store_ssb(ptr); } } return *ptr; } There's no TSD here, right. But now imagine that for some reason (e.g. mbars are "way too expensive"/"TSD is much faster"), we'll change that implementation to use the TSD (instead of atomic<>- with-memory-barriers)... class stuff { /* ... */ }; extern "C" void c_deleter_for_stuff(void * p) { delete static_cast(p); } template<> c_TSD_dtor_t c_TSD_dtor< deleter< stuff > >() { return c_deleter_for_int_ptr; } class thing { public: thing(/* ... */) : /* ... */ stuff_shared_ptr(0) /* ... */ { /*...*/ } ~thing() { /* ... */ delete stuff_shared_ptr; /* ... */ } /* ... */ const stuff & stuff_instance(); /* ... */ private: /* ... */ mutex stuff_mtx; stuff * stuff_shared_ptr; thread_specific_ptr stuff_thread_ptr; /* ... */ }; const stuff & thing::stuff_instance() { // "lazy" one stuff * ptr; if (0 == (ptr = stuff_thread_ptr.get())) { { mutex::guard guard(stuff_mtx); if (0 == (ptr = stuff_shared_ptr)) ptr = stuff_shared_ptr = new stuff(/*...*/); } stuff_thread_ptr.set(ptr); } return *ptr; } As you can see here, we don't use deleter to cleanup TSD because all threads share the same object and TSD is used only to ensure a proper memory synchronization. We use a "no_cleanup" thing that sets the TSD destructor to NULL (please see another DR "alt-tsdset-2003-05-23" for details). Do we really want to have clients care about such change in the implementation? I, for one, surely don't. I think that a compromise solution is needed here. Action: 1. Replace "The thread-specific data values associated with key need not be NULL at the time pthread_key_delete() is called." with "For a thread-specific data key with a NULL destructor pointer, the thread-specific data values associated with key need not be NULL at the time pthread_key_delete() is called; otherwise (for a thread-specific data key with a non-NULL destructor pointer), application must ensure that the thread-specific data values are NULL in all threads prior to key destruction." (or something like that) 2. consider adding a "may fail" error for implementations willing to detect and report erroneous deletion of "busy" keys. 3. "adjust" the following Rationale piece (I don't know how): Even if there were a means of safely freeing thread-specific data associated with keys to be deleted, doing so would require that implementations be able to enumerate the threads with non- NULL data and potentially keep them from creating more thread- specific data while the key deletion is occurring. This special case could cause extra synchronization in the normal case, which would otherwise be unnecessary. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 102 dragan@soliton.com Defect in XSH sem_init (rdvk# 102) {dc-sem-1} Fri, 30 May 2003 21:15:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Agreed as below with TMO markings _____________________________________________________________________________ Page: 1252 Line: 39019 Section: sem_init Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The list of functions that can be called after a successfull call to sem_init() does not include sem_timedwait(). Action: In lines 39027, 39031, 39033, 39035, please add sem_timedwait() (with appropriate shading). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 103 dragan@soliton.com Defect in XSH sem_open (rdvk# 103) {dc-sem-2} Fri, 30 May 2003 21:30:46 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As below with TMO marking _____________________________________________________________________________ Page: 1254 Line: 39071 Section: sem_open Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The list of functions that can be called after a successfull call to sem_open() does not include sem_timedwait(). Action: In lines 39080, please add sem_timedwait() (with appropriate shading). _____________________________________________________________________________ OBJECTION Enhancement Request Number 104 drepper@redhat.com Defect in XSH glob() (rdvk# 104) {ud-glob-mark} Wed, 4 Jun 2003 06:07:49 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The change is not needed. The standard requires that glob() follow symlinks and, therefore, is required to add a "/" to the end of a pathname that is a symlink pointing to a directory. Specifically, the definition of pathname resolution (XBD [2003 version], P102-103, L3164-3170) requires that a final component in a pathname that is a symlink be expanded unless all of the following are true: 1. This is the last pathname component of the pathname, 2. the pathname has no trailing slash, and 3. the function is required to act on the symlink itself. Since there is nothing in the description of glob() saying that it is required to act on the symlink itself, it is required to follow the symlink. Therefore, when GLOB_MARK is set in flags, the standard requires that symlinks pointing to directories be listed with a slash appended. _____________________________________________________________________________ Page: 577 Line: 18951 Section: glob() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The description of the GLOB_MARK option currently reads: GLOB_MARK Each pathname that is a directory that matches pattern shall have a slash appended. The question is, what happens to names of symlinks to directories? If the standard is what it is they are not marked. But I would expect them to be since the purpose of this option is it to visually mark the names which need recursing and allow appending names of files in the subdir directly without caring about the extra slash to add. Action: Change lines 18951f to: GLOB_MARK Each pathname that is a directory or a symbolic link to a directory that matches /pattern/ shall have a slash appended. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 105 ajosey@opengroup.org Defect in XSH sysconf (rdvk# 105) {_POSIX_SYMLOOP_MAX} Thu, 5 Jun 2003 10:57:10 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1474 Line: 45617 Section: sysconf Problem: Edition of Specification (Year): 2003 Defect code : 1. Error There is an entry for SYMLOOP_MAX in this table, there thus does not need to be an entry for _POSIX_SYMLOOP_MAX (the minimum maximum) here. Action: Delete _POSIX_SYMLOOP_MAX _SC_SYMLOOP_MAX on line 45617 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 106 ajosey@opengroup.org Defect in XSH sysconf (rdvk# 106) {_POSIX_V6_*} Thu, 5 Jun 2003 11:58:10 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The _V6_* symbols in should be changed to be _POSIX_V6_* symbols. These appear in three places in the standard: 1. XCU P216, L8494-8505 (in the c99 utility EXTENDED DESCRIPTION section) using _POSIX_V6_*, 2. XSH P1474-1475, L45637-45642 (in the sysconf() function DESCRIPTION section) using _POSIX_V6_*, and 3. XBD P405, L14309-14320 (in the header DESCRIPTION section) using _V6_*. I believe the original names were created for the c99 description and were correctly entered into the sysconf() table. I think we noticed later that they were missing from . My guess is that we used a shorthand notation to fix the problem and didn't notice the inconsistency when text was added to until now. _____________________________________________________________________________ Page: 1474 Line: 45637-45642 Section: sysconf Problem: Edition of Specification (Year): 2003 Defect code : 1. Error In the sysconf() page we list the following entries (all prefixed _POSIX_V6*) _POSIX_V6_ILP32_OFF32 _SC_V6_ILP32_OFF32 _POSIX_V6_ILP32_OFFBIG _SC_V6_ILP32_OFFBIG _POSIX_V6_LP64_OFF64 _SC_V6_LP64_OFF64 _POSIX_V6_LPBIG_OFFBIG _SC_V6_LPBIG_OFFBIG However there are no _POSIX_V6* defined symbols in unistd.h. We have _V6_* symbols, _SC_V6* symbols, and _CS_POSIX_V6* I suspect that we should have had the _V6_* symbols be _POSIX_V6* Action: This needs discussion. One course of corrective action could be to update the symbols in the first column of sysconf() to be _V6* rather than _POSIX_V6* . Alternately we could have _POSIX_V6*, and _SC_POSIX_V6* which would be consistent with the _CS_POSIX_V6* _____________________________________________________________________________ EDITORIAL Enhancement Request Number 107 ajosey@opengroup.org Defect in XSH sysconf (rdvk# 107) {_REGEX_VERSION} Thu, 5 Jun 2003 06:27:40 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1475 Line: 45659 Section: sysconf Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The sysconf() manual page includes the entry _REGEX_VERSION _SC_REGEX_VERSION, which was merged in from 1003.1a. There is no corresponding entry in unistd.h for these symbols. The text in .1a indicates it was to be used for versioning information related to the _SC_REGEXP_VERSION (sic) (.1a D17): "172 POSIX.2RE: The version of ISO/IEC 9945-2 that defines _POSIX2_VERSION to be the value indicated by the return value of sysconf(_SC_REGEXP_VERSION)." Given that the approach for "_SC_2_C_VERSION" and "_SC_XOPEN_XCU_VERSION" has been to remove them since they are unnecessary it would seem logical to be consistent and remove this entry. Action: Delete "_REGEX_VERSION _SC_REGEX_VERSION" on line 45659. _____________________________________________________________________________ OBJECTION Enhancement Request Number 108 gwc@lon.opengroup.org Defect in XSH y0 (rdvk# 108) [gwc y0 pole error] Tue, 10 Jun 2003 15:37:21 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1660 Line: 51168 Section: y0 Problem: Defect code : 1. Error The y0() page says "If x is 0.0, -HUGE_VAL shall be returned and a range error may occur." This is inconsistent with the general rules stated in "Treatment of Error Conditions for Mathematical Functions" in XBD which says: A "pole error" occurs if the mathematical result of the function is an exact infinity (for example, log(0.0)). I believe that for y0(), y1() and yn(), when x is zero the mathematical result is minus infinity. So this should be a pole error, not a range error. Action: Change "If x is 0.0, -HUGE_VAL shall be returned and a range error may occur" to "If x is 0.0, -HUGE_VAL shall be returned and a pole error may occur" On line 51179 change "The value of x is 0.0, or the correct result would cause overflow" to "The correct result would cause overflow". Insert before line 51179: Pole error The value of x is zero. If the integer expression (math_errhandling & MATH_ERRNO) is non-zero, then errno shall be set to [ERANGE]. If the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, then the divide-by-zero floating-point exception shall be raised. _____________________________________________________________________________ OBJECTION Enhancement Request Number 109 drepper@redhat.com Defect in XSH Threads (rdvk# 109) {ud-cp-1} Wed, 18 Jun 2003 09:06:57 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 55 Line: 2267 Section: Threads Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission fsync() is among the cancellation points. The fdatasync() function isn't although it is very similar. Action: Add fdatasync() to list of cancellation points. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 110 ajosey@opengroup.org Defect in XSH pselect (rdvk# 110) {pselect.signal.mask.process} Mon, 16 Jun 2003 19:16:09 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as the "calling thread" _____________________________________________________________________________ Page: 975 Line: 31069 Section: pselect Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text talks about the signal mask of the process,and probably should be the signal mask of the calling thread ("the caller") Action: Change from: If sigmask is not a null pointer, then the pselect( ) function shall replace the signal mask of the process by the set of signals pointed to by sigmask before examining the descriptors, and shall restore the signal mask of the process before returning. To: If sigmask is not a null pointer, then the pselect( ) function shall replace the signal mask of the caller by the set of signals pointed to by sigmask before examining the descriptors, and shall restore the signal mask of the caller before returning. (if you want to be more explicit , we could say "calling thread" instead of "caller) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 111 don.cragun@sun.com Defect in XSH realpath() (rdvk# 111) {dwc-realpath.1} Tue, 17 Jun 2003 19:59:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1190 Line: 37082,37092 Section: realpath() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The descriptions of the ELOOP errors on this page refer to the path argument, but there is no path argument to realpath(). Action: Change "path" on P1190, L37082 to "file_name". Change "path" on P1190, L37092 to "file_name". _____________________________________________________________________________ OBJECTION Enhancement Request Number 112 sean.dorward@sandbridgetech.com Defect in XSH sem_close (rdvk# 112) {1} Tue, 10 Jun 2003 18:43:49 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_97 Reject_____ Rationale for rejected or partial changes: Dup of ERN 97 _____________________________________________________________________________ Page: 1243 Line: 38674-38677 Section: sem_close Problem: Edition of Specification (Year): 2001 Defect code : 2. Omission The standard says that upon a successful sem_close call, system shall deallocate all resources allocated to the process for the use of this semaphore. This appears to imply that a sempaphore which has been opened multiple times (without intervening calls to sem_unlink) will be deallocated on the first close. For example, s1 = sem_open("/foo", ...); s2 = sem_open("/foo", ...); assert(s1 == s2); sem_close(s1); would leave s2 invalid. Action: Change the wording from "The sem_close function shall" to "When the sem_close function has been called the same number of times as successful sem_open calls returning the semaphore descriptor sem, it shall" _____________________________________________________________________________ COMMENT Enhancement Request Number 113 ajosey@opengroup.org Defect in XSH sighold (rdvk# 113) {sighold-and-sysv-signals} Thu, 19 Jun 2003 09:27:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Store this request in a numbered document in the docreg items to consider _____________________________________________________________________________ Page: 1357 Line: 42176 Section: sighold Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required This comment was passed to me , I am filing an aardvark so it can be considered for a future revison, if appropriate: Since the SVID signal functions were intentionally omitted from the original POSIX signal work, in favor of the superior functionality of the sigaction()/sigsuspend() family, I think it was something of a mistake that these functions were not at least deprecated in the merge. I would appreciate it if you could raise this issue with TOG's membership so that this mistake need not be carried past the next revision cycle. Action: Mark the functions on this page as legacy in a future revision. _____________________________________________________________________________ COMMENT Enhancement Request Number 114 loic-dev@gmx.net Defect in XSH pthread_sigmask (rdvk# 114) {pthread_sigmask} Fri, 11 Jul 2003 14:33:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Signalling in multi-threaded process. This example shows the use of pthread_sigmask() in order to deal with signals in a multi-threaded process. It provides a fairly general framework that could be easily adapted/extended by the reader. (example replaced with text from austin-review-l #1566) /*===== Include part ===========================================*/ /*==============================================================*/ #include #include #include #include #include #include ... static sigset_t signal_mask; /* signals to block */ int main (int argc, char *argv[]) { pthread_t sig_thr_id; /* signal handler thread ID */ int rc; /* return code */ sigemptyset (&signal_mask); sigaddset (&signal_mask, SIGINT); sigaddset (&signal_mask, SIGTERM); rc = pthread_sigmask (SIG_BLOCK, &signal_mask, NULL); if (rc != 0) { /* handle error */ ... } /* any newly created threads inherit the signal mask */ rc = pthread_create (&sig_thr_id, NULL, signal_thread, NULL); if (rc != 0) { /* handle error */ ... } /* APPLICATION CODE */ ... } void *signal_thread (void *arg) { int sig_caught; /* signal caught */ int rc; /* returned code */ rc = sigwait (&signal_mask, &sig_caught); if (rc != 0) { /* handle error */ } switch (sig_caught) { case SIGINT: /* process SIGINT */ ... break; case SIGTERM: /* process SIGTERM */ ... break; default: /* should normally not happen */ fprintf (stderr, "\nUnexpected signal %d\n", sig_caught); break; } } _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_sigmask Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Missing example Action: Signalling in multi-threaded process. This example shows the use of pthread_sigmask() in order to deal with signals in a multi-threaded process. It provides a fairly general framework that could be easily adapted/extended by the reader. (example replaced with text from austin-review-l #1566) /*===== Include part ===========================================*/ /*==============================================================*/ #include #include #include #include #include #include ... /*===== Signal's list to be managed ===========================*/ /*==============================================================*/ /* * in this example, we want to handle SIGINT, SIGQUIT and SIGTERM */ static int psig_list[] = {SIGINT, SIGQUIT, SIGTERM}; /*===== Usefull macros =========================================*/ /*==============================================================*/ #define NELEMS_ARRAY(array) ( sizeof(array)/sizeof(array[0]) ) #define DIE(text, error_code) \ die(text, error_code, __func__, __LINE__) /*===== Struct, typedefs etc. ==================================*/ /*==============================================================*/ typedef void* (*pthread_routine_t)(void *); /*===== Forward declaration ====================================*/ /*==============================================================*/ void signal_thread(void); void create_sigmask(sigset_t*, const int[], const int); void die(const char*, const int, const char*, const int); /****************************************************************/ /* main() */ /****************************************************************/ int main(int argc, char **argv ) { pthread_t sig_thr_id; /* signal handler thread ID */ sigset_t sig_to_block; /* signals to block */ int rc; /* return code */ /*------------------------------------------------------------*/ /* Install the mechanism to deal with the "process-oriented" */ /* signals listed in psig_list[]. */ /*------------------------------------------------------------*/ /* * Set the initial thread's signal mask to block * the signals listed in psig_list */ create_sigmask (&sig_to_block, psig_list, NELEMS_ARRAY(psig_list) ); rc = pthread_sigmask (SIG_BLOCK, &sig_to_block, (sigset_t*) NULL ); if (rc != 0) { DIE("pthread_sigmask()", rc); /* die on error */ } /* * Start a dedicated thread to handle signalling */ rc = pthread_create (&sig_thr_id, (pthread_attr_t*) NULL, (pthread_routine_t) signal_thread, (void*) NULL ); if (rc != 0) { DIE("pthread_create()", rc); /* die on error */ } /* * At this point, any newly created thread will inherit * the signal mask from the initial thread. Thus these * threads shall not need to block again these signals. */ /*------------------------------------------------------------*/ /* Do whatever the program has to do (initialize, create */ /* threads an so on). */ /*------------------------------------------------------------*/ ... } /****************************************************************/ /* signal_thread */ /****************************************************************/ /* */ /* the signal thread waits for a signal listed in psig_list[] */ /* to be queued. Upon reception of a targeted signal, it does */ /* the corresponding processing. */ /* */ /****************************************************************/ void signal_thread(void) { sigset_t sig_to_wait4; /* signals to wait for */ int sig_caught; /* signal caught */ int rc; /* returned code */ /*------------------------------------------------------------*/ /* wait for one signal in psig_list[] to become pending */ /*------------------------------------------------------------*/ create_sigmask (&sig_to_wait4, psig_list, NELEMS_ARRAY(psig_list) ); rc = sigwait (&sig_to_wait4, &sig_caught ); if (rc != 0) { DIE("sigwait()", rc); /* die on error */ } /*------------------------------------------------------------*/ /* react accordingly to the signal caught */ /*------------------------------------------------------------*/ switch (sig_caught) { case SIGINT: /* process SIGINT */ ... break; case SIGQUIT: /* process SIGQUIT */ ... break; case SIGTERM: /* process SIGTERM */ ... break; default: /* should normally not happen */ fprintf (stderr, "\nOups BUG! Forgot to deal with signal %d\n", sig_caught ); break; } ... } /****************************************************************/ /* create_sigmask */ /****************************************************************/ /* */ /* this functions creates the signal mask corresponding to the */ /* n signals listed in list[]. */ /* */ /****************************************************************/ void create_sigmask(sigset_t *ptr_sigmask, /* returned sigmask */ const int list[], /* list of signals */ const int n /* number of signals*/ ) { /* * Define the list of "hardware trap" */ static int hwtraps[] = {SIGFPE, SIGILL, SIGSEGV, SIGBUS}; int i; int rc; /*------------------------------------------------------------*/ /* Set sigmask to be the union of signal listed list[] */ /*------------------------------------------------------------*/ rc = sigemptyset (ptr_sigmask); for (i=0; i\n", errno ); } else { /* print error message string */ fprintf (stderr, "%s.\n", error_string ); } /*-------------------------------------------------------------*/ /* Terminate the process */ /*-------------------------------------------------------------*/ exit (EXIT_FAILURE); } --- This example is quite long, but has the advantage to explain in large extend the standard mechanism to handle signalling in a multi-threaded process. Furthermore, it provides also example for exit(), pthread_create(), sigwait(), sigemptyset(), sigaddset(), and sigdelset(). If this example is too long, we might break it on several interfaces. I hope that Aardvark will be pleased with the current formatting. In case of problems, let me know! Feedbacks about this example are definitively appreciated!! Thanks, Loic. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 115 rochkind@basepath.com Defect in XSH asctime (rdvk# 115) {1} Fri, 20 Jun 2003 18:51:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Current wording is aligned with ISO C. It is possible to get errors, especially when you have 64 bit time values. Also see http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_217.htm for information. It was agreed to add a CX extension at the end of line 4419 p 121 (2001 Ed) [CX] If the function is unsuccessful, it shall return NULL. [/CX] The committee did not take time to search the standard for other places where similar issues occur _____________________________________________________________________________ Page: 0 Line: 0 Section: asctime Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required Under RETURN VALUE, it states, "Upon successful completion, asctime() shall return a pointer to the string." The phrase "Upon successful completion" implies that unsuccessful completion is possible, in which case it should state what it returns. If successful completion is the only possibility, the phrase should be dropped, as it's confusing. Action: As above, depending on the intended meaning. Clive Feather responds: This was addressed in a C Defect Report. The decision was that the behaviour is undefined (including cases such as when the year has 5 digits and so the provided space is insufficient). http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_217.htm _____________________________________________________________________________ EDITORIAL Enhancement Request Number 116 mtk-lists@gmx.net Bug in TC2-d2 wait() (rdvk# 116) {XSH-wait-example} Tue, 8 Jul 2003 16:54:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: [Summary line] Waiting for a child process and then checking its status The following example demonstrates the use of waitpid(), fork(), and the macros used to interpret the status value returned by waitpid() (and wait()). The code segment creates a child process which does some unspecified work. Meanwhile the parent loops performing calls to waitpid() to monitor the status of the child. The loop terminates when child termination is detected. #include #include #include #include ... pid_t child_pid, wpid; int status; child_pid = fork(); if (child_pid == -1) { /* fork() failed */ perror("fork"); exit(EXIT_FAILURE); } if (child_pid == 0) { /* This is the child */ /* Child does some work and then terminates */ ... } else { /* This is the parent */ do { wpid = waitpid(child_pid, &status, WUNTRACED #ifdef WCONTINUED /* Not all implementations support this */ | WCONTINUED #endif ); if (wpid == -1) { perror("waitpid"); exit(EXIT_FAILURE); } if (WIFEXITED(status)) { printf("child exited, status=%d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("child killed (signal %d)\n", WTERMSIG(status)); } else if (WIFSTOPPED(status)) { printf("child stopped (signal %d)\n", WSTOPSIG(status)); #ifdef WIFCONTINUED /* Not all implementations support this */ } else if (WIFCONTINUED(status)) { printf("child continued\n"); #endif } else { /* Non-standard case -- may never happen */ printf("Unexpected status (0x%x)\n", status); } } while (!WIFEXITED(status) && !WIFSIGNALED(status)); } _____________________________________________________________________________ Page: 1 Line: 49061 Section: wait() Problem: This is an EXAMPLE for the waitpid() man page. The example is somewhat long, but it could also be cited as an EXAMPLE for fork() (line 12809). I havent much experience submitting Aardvarks, hopefully everything here is done right. Line number references are to TC1. I have included error handling for fork() and waitpid() this may or may not be desired (for space reasons). Action: Change "None" to the following: [[ [Summary line] Waiting for a child process and then checking its status The following example demonstrates the use of waitpid(), fork(), and the macros used to interpret the status value returned by waitpid() (and wait()). The code segment creates a child process which does some unspecified work. Meanwhile the parent loops performing calls to waitpid() to monitor the status of the child. The loop terminates when child termination is detected. #include #include #include #include ... pid_t child_pid, wpid; int status; child_pid = fork(); if (child_pid == -1) { /* fork() failed */ perror("fork"); exit(EXIT_FAILURE); } if (child_pid == 0) { /* This is the child */ /* Child does some work and then terminates */ } else { /* This is the parent */ do { wpid = waitpid(child_pid, &status, WUNTRACED #ifdef WCONTINUED /* Not all implementations have this */ | WCONTINUED #endif ); if (wpid == -1) { perror("waitpid"); exit(EXIT_FAILURE); } if (WIFEXITED(status)) { printf("child exited, status=%d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("child killed (signal %d)\n", WTERMSIG(status)); } else if (WIFSTOPPED(status)) { printf("child stopped (signal %d)\n", WSTOPSIG(status)); #ifdef WIFCONTINUED /* Not all implementations have this */ } else if (WIFCONTINUED(status)) { printf("child continued\n"); #endif } else { /* Non-standard case -- may never happen */ printf("Unexpected status (0x%x)\n", status); } } while (!WIFEXITED(status) && !WIFSIGNALED(status)); } _____________________________________________________________________________ OBJECTION Enhancement Request Number 117 bmark@us.ibm.com Defect in XSH lio_listio() (rdvk# 117) {IBM-062401} Tue, 24 Jun 2003 15:23:15 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: Ulrich thinks its correct as it is, thought to be a defect in ISO C 99 Fred T has file a DR. We should put this on hold. Leave this open pending the C99 DR _____________________________________________________________________________ Page: 686 Line: 22683 Section: lio_listio() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error We believe that the function prototype of lio_listio(): int lio_listio(int, struct aiocb *restrict const[restrict],int, struct sigevent *restrict); is in violation of ISO C99. This is what our compiler produces.... "cc23es.c", line 78.66: 1506-865 (W) Static or type qualifier(s) allowed only in the outer most array index of a function parameter. Keyword(s) ignored. According to our compiler developers this line violates section 6.7.6(direct-abstract-declarator) of the C99 standard. The identifier name must be used as per section 6.7.5(direct-declarator)". The line needs to be changed to something like the following: int lio_listio(int, struct aiocb *restrict const __FOO[restrict], int, struct sigevent *restrict); The type names used in the code are identical to the ones in the lio_listio() prototype on the page in XBD6. -------------- Some commentary by Geoff Clare: I'm wondering if this is actually a bug in C99. In particular section 6.7.6 states that a type name "is syntactically a declaration for a function or an object of that type that omits the identifier." So you would think that if struct aiocb *restrict const __FOO[restrict] is a valid declaration of the object __FOO, then it should follow from the above statement that struct aiocb *restrict const [restrict] must be a valid type name. It certainly seems odd that the formal syntax given in 6.7.6 is not equivalent to the syntax given in 6.7.5 with just the parts related to identifiers removed. ------------------ Action: The syntax needs to be ISO C99-conforming. Allow the alternate syntax as valid until we can get a clarification from ISO. ______________________________________________________________________________ COMMENT Enhancement Request Number 118 terekhov@web.de Defect in XSH pthread_cond_timedwait() (rdvk# 118) {alt-cv.timedwait-2003-07-11} Fri, 11 Jul 2003 17:15:12 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We rejected the argument below because a condition variable does not have state, and if there is no other thread waiting the signal is gone. The application needs to recheck the predicate on any return because it cannot be sure there is another thread waiting on the thread to handle the signal, and if there is not then signal is lost. The burden is on the application to check the predicate. Add additional RATIONALE: The application needs to recheck the predicate on any return because it cannot be sure there is another thread waiting on the thread to handle the signal, and if there is not then the signal is lost. The burden is on the application to check the predicate. ______________________________________________________________________________ Page: 1036 Line: 32668-32671 Section: pthread_cond_timedwait() Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The standard says: The pthread_cond_timedwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned if the absolute time specified by abstime passes (that is, system time equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call. It isn't clear (you might want but not need to follow the link that can be found below) whether a thread that has been unblocked because its wait has been timedout while blocked in a call to pthread_cond_timedwait() may consume a condition signal that may be directed concurrently at the condition variable if there are other threads blocked on the condition variable. http://google.com/groups?threadm=bej397%24ho9%241%40nntp.webmaster.com (Subject: Strange mutex question, can a timeout satisfy a signal?) Action: add the following (or something like that) after 32671: A thread that has been unblocked because its wait has been timedout while blocked in a call to pthread_cond_timedwait() may consume a condition signal (not more than one) that may be directed concurrently at the condition variable even if there are other threads blocked on the condition variable. -OR- (I really don't like it, but others disagree) add the following (or something like that) after 32671: A thread that has been unblocked because its wait has been timedout while blocked in a call to pthread_cond_timedwait() shall not consume any condition signal that may be directed concurrently at the condition variable if there are other threads blocked on the condition variable. _____________________________________________________________________________ COMMENT Enhancement Request Number 119 loic-dev@gmx.net Defect in XSH exp (rdvk# 119) {exp} Wed, 16 Jul 2003 16:18:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: p313 line 10264 2003 ed Computing the density of the standard normal distribution This function shows an implementation for the density of the standard normal distribution using exp(). This example uses the constant M_PI which is an XSI extension. #include double normal_density (double x ) { return exp(-x*x/2) / sqrt (2*M_PI); } _____________________________________________________________________________ Page: 0 Line: 0 Section: exp Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Missing Example. Action: (replaced with austin-review-l 1581) Computing the density of the standard normal distribution This function shows a straightforward implementation for the density of the standard normal distribution using exp() #include double normal_density (double x ) { return exp(-x*x/2) / sqrt (2*M_PI); } Note: For real life problems, where normal_density() is called many, many times (let's say 10 millions or more), this implementation is not particularly efficient. Possible improvements include: - compute the constant term sqrt(2*M_PI) only once. - transform the division to a multiplication. If you are planning to do serious numerical works, get a good book on numerical computations or advices from an expert. [ I guess this last advice applies to all XSH math functions ] _____________________________________________________________________________ COMMENT Enhancement Request Number 120 loic-dev@gmx.net Defect in XSH erf (rdvk# 120) {erf} Wed, 16 Jul 2003 16:52:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Computing the probability for a normal variate This example shows how to use erf() to compute the probability that a normal variate assumes a value in the range [x1,x2] with x1<=x2. This example uses the constant M_SQRT1_2 which is an XSI extension. #include double Phi(const double x1, const double x2) { return ( erf(x2*M_SQRT1_2) - erf(x1*M_SQRT1_2) ) / 2; } _____________________________________________________________________________ Page: 0 Line: 0 Section: erf Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Missing Example. Action: Computing the probability for a normal variate This example shows how to use erf() to compute the probability that a normal variate assumes a value in the range [x1,x2] with x1<=x2. #include double Phi(const double x1, const double x2 ) { return ( erf(x2*M_SQRT1_2) - erf(x1*M_SQRT1_2) ) / 2; } _____________________________________________________________________________ COMMENT Enhancement Request Number 121 loic-dev@gmx.net Defect in XSH fabs (rdvk# 121) {fabs} Wed, 16 Jul 2003 14:58:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Computing the 1-norm of a floating point vector This example shows the use of fabs() to compute the 1-norm of a vector defined as follows: norm1(v) = |v[0]| + |v[1]| + ... + |v[n-1]| where |x| denotes the absolute value of x, n denotes the vector's dimension v[i] denotes the i-th component of v (0<=i double norm1(const double v[], const int n ) { int i; double n1_v; /* 1-norm of v */ n1_v = 0; for (i=0; i double norm1(const double v[], /* vector components */ const int n /* vector dimension */ ) { int i; double n1_v; /* 1-norm of v */ n1_v = 0; for (i=0; i void cartesian_to_polar(const double x, const double y, double *rho, double *theta ) { *rho = hypot (x,y); /* better than sqrt(x*x+y*y) */ *theta = atan2 (y,x); } _____________________________________________________________________________ Page: 0 Line: 0 Section: atan2 Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Missing example. Action: Converting Cartesian to Polar coordinates system The function below uses atan2() to convert a 2d vector expressed in cartesian coordinates (x,y) to the polar coordinates (rho,theta). #include void cartesian_to_polar(const double x, const double y, /* cartesian */ double *rho, double *theta /* polar */ ) { *rho = hypot (x,y); /* better than sqrt(x*x+y*y) */ *theta = atan2 (y,x); } [[ Notes to the reviewers: - similar examples might be derived using atan2f(), atan2l(). - In this revised version, I have used hypot() as suggested by Fred T. Sure it could also serve to illustrate hypot(), but I believe it is better to provide another example for hypot(). - In my opinion, it would be valuable to add some explanations right after the example _if_ the editorial constraints allow it. Namely: " There are alternative ways to compute the angle theta, using e.g. asin(), acos() or atan(). However, atan2() presents here two advantages: - the angle's quadrant is automatically determined. - the singular cases (0,y) are taken into account. Finally, using hypot() is better than sqrt() for special cases, refer to " end of notes to the reviewers ]] _____________________________________________________________________________ COMMENT Enhancement Request Number 124 loic-dev@gmx.net Defect in XSH pthread_attr_getguardsize (rdvk# 124) {pthread_attr_getguardsize} Mon, 21 Jul 2003 17:10:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Retrieving the guardsize attribute. This example shows how to obtain the guardsize attribute of a thread attribute object. #include pthread_attr_t thread_attr; size_t guardsize; int rc; /* code initializing thread_attr */ ... rc = pthread_attr_getguardsize (&thread_attr, &guardsize); if (rc != 0) { /* handle error */ ... } else { if (guardsize > 0) { /* a guard area of at least guardsize bytes is provided */ ... } else { /* no guard area provided */ ... } } _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_attr_getguardsize Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Missing example. Action: Retrieving the guardsize attribute. This example shows how to obtain the guardsize attribute of a thread attribute object. #include pthread_attr_t thread_attr; /* thread attribute object */ size_t guardsize; /* guardsize */ int rc; ... rc = pthread_attr_getguardsize (&thread_attr, &guardsize); if (rc != 0) { /* handle error */ ... } else { if (guardsize > 0) { /* a guard area of at least guardsize bytes is provided */ ... } else { /* no guard area not provided */ ... } } _______________________________________________________________________________ COMMENT Enhancement Request Number 125 loic-dev@gmx.net Defect in XSH pthread_attr_getdetachstate (rdvk# 125) {pthread_attr_getdetachstate} Mon, 21 Jul 2003 14:55:17 +0100 (BST) ____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Retrieving the detachstate attribute. This example shows how to obtain the detachstate attribute of a thread attribute object. #include pthread_attr_t thread_attr; int detachstate; int rc; /* code initializing thread_attr */ ... rc = pthread_attr_getdetachstate (&thread_attr, &detachstate); if (rc!=0) { /* handle error */ ... } else { /* legal values for detachstate are: * PTHREAD_CREATE_DETACHED or PTHREAD_CREATE_JOINABLE */ ... } _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_attr_getdetachstate Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Missing example. Action: Retrieving the detachstate attribute. This example shows how to obtain the detachstate attribute of a thread attribute object. #include pthread_attr_t thread_attr; /* thread attribute object */ int detachstate; /* detachstate attribute */ int rc; ... rc = pthread_attr_getdetachstate (&thread_attr, &detachstate); if (rc!=0) { /* handle error */ ... } else { /* legal values for detachstate are: * PTHREAD_CREATE_DETACHED or PTHREAD_CREATE_JOINABLE */ ... } [[ Note to the reviewers: The pthread_attr_set* XSH refer to the pthread_attr_get*. So, maybe we should incorporate also a "set" example? Or Do you think, it is sufficient to just illustrate the pthread_attr_get*? A point that causes me headaches is the following. Not all Pthreads implementations check the validity of the attr parameter. If I understood correctly, the standard doesn't require such a check. As a result, pthread_attr_getdetachstate() might returns 0, but detachstate has some garbage value, since the implementation accesses the memory thinking that's a pthread_attr_t. That's what I wanted to convey with the comments in the else clause. After long considerations whether we should inform or not the reader about this potential issue, I decide to silently ignore the problem following Dave (Butenhof) statement: " The standard is not designed to make UNIX, or signals, or threads, or async I/O, or anything else "safe" for inexperienced programmers. " However in view of ERN91, we could also make things "more convenients" for this particular problem ;-) "strong" Pthreads implementations already support this. end of notes to the reviewers ]] ______________________________________________________________________________ EDITORIAL Enhancement Request Number 126 rochkind@basepath.com Defect in XSH Error Numbers (rdvk# 126) {errors} Sat, 19 Jul 2003 22:05:32 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In gettaddrinfo ERRORS section Change From: "The getaddrinfo() function shall fail and return the corresponding value if:" To: "The getaddrinfo() function shall fail and return the corresponding error value if:" _____________________________________________________________________________ Page: 0 Line: 0 Section: System Problem: Edition of Specification (Year): 2003 Defect code : 1. Error In the section "System Interfaces/General Information/Error Numbers" it states "Some functions return an error number directly as the function value." It would be helpful if the term "error number" were defined in "Base Definitions/Definitions." getaddrinfo and getnameinfo are specified to return a "value," not an error number, and this is an important distinction. This term, "value," should be in the Definitions as well, but clearly, before doing so, a more precise term should be invented. (Or not; see below.) strerror and strerror_r are specified to take an "error number" as their first argument, which is fine, as the careful reader would know not to pass in a "value." Well, maybe not, because "strerror() shall map any value of type int to a message," which seems hard to implement, until one realizes that a return of, say, "Unknown value," completely meets the spec. The term "value" should not be used, however, because, although the "values" returned by getaddrinfo and getnameinfo work on all the implementations I tried, and they do return a message as required, the message is totally unrelated to the actual error. Surely this is not a useful implementation, and the spec should steer implementors away from it. A "value" must instead be passed to gai_strerror, which is specified to take an "error value." It's very clearly worded, but, still, it ought to use exactly the same term as getaddrinfo and getnameinfo do, not an approximation, as the reader could easily confuse the two terms "error number" and "error value," which are, of course, completely different things; the latter is the same as a "value." Merely touching up the terminology and adding some definitions doesn't really address the problem. The real problem is that there are three functions (getdate is one) in the entire SUS that don't follow the "error number" scheme, and they could easily be changed to merge everything together. Action: 1. Keep the EAI_* codes, but change the specification for getaddrinfo and getnameinfo to say that they return an error number. 2. In the section "System Interfaces/General Information/Error Numbers" and the specification for errno.h, make it clear that the EAI_* symbols are error numbers, too. (Implementations that overlap the actual values of the EAI_* constants with errno values will have to change.) If anyone is bothered by the use of "EAI_" for an errno constant, define a set of synonyms that follow the "E*" pattern. 3. getdate is unusual because it uses actual numbers (1 - 8), not macros for its error indication, which it confusingly calls a "value" and returns through getdate_err. I would suggest that getdate be changed to specify that errno shall be set to one of 8 new constants to be defined. For compatibility, we can leave getdate_err and the numbers 1 - 8 alone. That is, on an error, an implementation would have to set getdate_err and errno, and the values they are set to are not necessarily the same. (It's perfectly OK with me if getdate_err and the numbers 1 - 8 are scrapped, but others care much more than I do about compatibility.) 4. With the new "error numbers," implementations of strerror, strerror_r, and perror have a bit more work to do, but since implementations are surely table-driven, this should be an easy upgrade. 5. I lied about there being only three weird functions; actually we also have gethostbyaddr and gethostbyname, which return their own values in their own global, h_errno. However, these functions are obsolete, so maybe there's no point in fixing them. The APPLICATION USAGE and FUTURE DIRECTIONS already indicate that they are deprecated (not sure if SUS uses that term officially). 6. For any function that returns an error indication, where the spec currently doesn't say that errno shall be set, it should be modified to say so. All is OK where errors are defined, but there are functions like time where it is stated that -1 is returned on an error, but nothing is said about errno. If an implementation defines any errors, it should be required to set errno. An example of the way to do it is uname, which specifies that errno shall be set, even though the spec doesn't define any errors. Now, with all these changes, we have only one pool of distinct "error numbers," and they are delivered to an application in only one of two ways: as a return value, or as a value of errno. Closing comment: One reason that a simple, easy-to-understand error-reporting mechanism is so critical is that in many cases testing can't be used to check that the application is showing (or logging, whatever) the correct error code, since the circumstances under which they are generated are too difficult to trigger and because the programmer's system may not even implement them. Proposed response: ------------------ Reject: > Edition of Specification (Year): 2003 > > Defect code : 1. Error > > In the section "System Interfaces/General Information/Error Numbers" >it states "Some functions return an error number directly as the function >value." It would be helpful if the term "error number" were defined in >"Base Definitions/Definitions." If this were done it should be a short dictionary definition (no normative requirements) and then reference XSH Section 2.4. I expect the view to date is that since ERROR NUMBERS have always had their own section in the standard that this was unnecessary. > > getaddrinfo and getnameinfo are specified to return a "value," >not an error number, and this is an important distinction. This term, >"value," should be in the Definitions as well, but clearly, before doing >so, a more precise term should be invented. (Or not; see below.) These interfaces were designed from the outset to be thread safe. I'd say "value" is being used in its common dictionary sense and is unnecessary for a definition -- a definition is something you would substitute in for the word, and "value" seems succint and precise. The term "error number" is not used since these (the EAI_* values) are not error numbers as defined in XSH Section 2.4 > > strerror and strerror_r are specified to take an "error number" as >their first argument, which is fine, as the careful reader would know >not to pass in a "value." Well, maybe not, because "strerror() shall >map any value of type int to a message," which seems hard to implement, >until one realizes that a return of, say, "Unknown value," completely >meets the spec. The term "value" should not be used, however, because, >although the "values" returned by getaddrinfo and getnameinfo work on all >the implementations I tried, and they do return a message as required, >the message is totally unrelated to the actual error. Surely this is >not a useful implementation, and the spec should steer implementors away >from it. The specification leaves it unspecified the relationship between what is passed in and the strings out and explicitly states that it should handle all values of type int. A specified way to retrieve the strings associated with the EAI_* values is gai_strerror(). > > A "value" must instead be passed to gai_strerror, which is specified >to take an "error value." It's very clearly worded, but, still, it ought >to use exactly the same term as getaddrinfo and getnameinfo do, not an >approximation, as the reader could easily confuse the two terms "error >number" and "error value," which are, of course, completely different >things; the latter is the same as a "value." The text regarding "value" is stated under the ERRORS section in getnameinfo(), this is clear to me. netdb.h also states (where it defines EAI_* ) "The header shall define the following macros for use as error values for getaddrinfo() and getnameinfo():" At most an editorial change could be to insert the word error, as in Change From: "The getaddrinfo() function shall fail and return the corresponding value if:" To: "The getaddrinfo() function shall fail and return the corresponding error value if:" > > Merely touching up the terminology and adding some definitions doesn't >really address the problem. The real problem is that there are three >functions (getdate is one) in the entire SUS that don't follow the >"error number" scheme, and they could easily be changed to merge >everything together. There could be an argument that we should have added the EAI_* values to XSH 2.4, and then redo the getnameinfo() and getaddrinfo() error pages are per the style used on the pthread* pages. But given that these are not defined as being in errno.h, and are thus not error numbers , what we have does make sense. The following changes proposed below , are changes to the specification and thus would require implementations to change. > > Action: > > 1. Keep the EAI_* codes, but change the specification for getaddrinfo >and getnameinfo to say that they return an error number. No, the EAI_* codes are not error numbers, error numbers are defined in errno.h, these values are defined in netdb.h > 2. In the section "System Interfaces/General Information/Error Numbers" >and the specification for errno.h, make it clear that the EAI_* symbols >are error numbers, too. (Implementations that overlap the actual values >of the EAI_* constants with errno values will have to change.) If anyone >is bothered by the use of "EAI_" for an errno constant, define a set of >synonyms that follow the "E*" pattern. No, this would be an over burden for implementations to have to change > 3. getdate is unusual because it uses actual numbers (1 - 8), not >macros for its error indication, which it confusingly calls a "value" >and returns through getdate_err. I would suggest that getdate be changed >to specify that errno shall be set to one of 8 new constants to be >defined. For compatibility, we can leave getdate_err and the numbers >1 - 8 alone. That is, on an error, an implementation would have to set >getdate_err and errno, and the values they are set to are not necessarily >the same. (It's perfectly OK with me if getdate_err and the numbers 1 - 8 >are scrapped, but others care much more than I do about compatibility.) What is the value in changing getdate(), does that help existing application code? The API is here precisely to align with the SVID definition. > 4. With the new "error numbers," implementations of strerror, >strerror_r, and perror have a bit more work to do, but since >implementations are surely table-driven, this should be an easy upgrade. This is also a change , and the gai_strerror() function is here precisely for this case (evidence that the standard developers knew that these are distinct items) > 5. I lied about there being only three weird functions; actually we >also have gethostbyaddr and gethostbyname, which return their own values >in their own global, h_errno. However, these functions are obsolete, >so maybe there's no point in fixing them. The APPLICATION USAGE and >FUTURE DIRECTIONS already indicate that they are deprecated (not sure >if SUS uses that term officially). Yes these are obsolete. > > 6. For any function that returns an error indication, where the spec >currently doesn't say that errno shall be set, it should be modified to >say so. All is OK where errors are defined, but there are functions like >time where it is stated that -1 is returned on an error, but nothing is >said about errno. If an implementation defines any errors, it should be >required to set errno. An example of the way to do it is uname, which >specifies that errno shall be set, even though the spec doesn't define >any errors. No, this misses a couple of points, firstly sometimes errors occur without setting errno. Secondly error cases can occur that are unspecified outside of the standard. > > Now, with all these changes, we have only one pool of distinct "error >numbers," and they are delivered to an application in only one of two ways: as >a return value, or as a value of errno. > > Closing comment: One reason that a simple, easy-to-understand >error-reporting mechanism is so critical is that in many cases testing >can't be used to check that the application is showing (or logging, >whatever) the correct error code, since the circumstances under >which they are generated are too difficult to trigger and because the >programmer's system may not even implement them. If we were starting from scratch I could see this argument,but unfortunately we are not. _____________________________________________________________________________ COMMENT Enhancement Request Number 127 mtk-lists@gmx.net Bug in TC2-d2 pipe() (rdvk# 127) {pipe example} Fri, 18 Jul 2003 14:27:57 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: [Summary line] Using a pipe to pass data between a parent process and a child process The following example demonstrates the use of a pipe to transfer data between a parent process and a child process. Error handling is excluded, but otherwise this code demonstrates good practice when using pipes: after the fork() the two processes close the unused ends of the pipe before they commence transferring data. #include #include ... int fildes[2]; const int BSIZE = 100; char buf[BSIZE]; ssize_t nbytes; int status; status = pipe(fildes); if (status == -1 ) { /* an error occurred */ .... } switch (fork()) { case -1: /* Handle error */ break; case 0: /* Child - reads from pipe */ close(fildes[1]); /* Write end is unused */ nbytes = read(fildes[0], buf, BSIZE); /* Get data from pipe */ /* At this point, a further read would see end of file... */ close(fildes[0]); /* Finished with pipe */ exit(EXIT_SUCCESS); default: /* Parent - writes to pipe */ close(fildes[0]); /* Read end is unused */ write(fildes[1], "Hello world\n", 12); /* Write data on pipe */ close(fildes[1]); /* Child will see EOF */ exit(EXIT_SUCCESS); } ]] _____________________________________________________________________________ Page: 1 Line: 27866 Section: pipe() Problem: This is an EXAMPLE for the waitpid() man page. Line number references are to TC1. Action: Change "None" to the following: [[ [Summary line] Using a pipe to pass data between a parent process and a child process The following example demonstrates the use of a pipe to transfer data between a parent process and a child process. Error handling is excluded, but otherwise this code demonstrates good practice when using pipes: after the fork() the two processes close the unused ends of the pipe before they commence transferring data. #include #include ... int fildes[2]; const int BSIZE = 100; char buf[BSIZE]; ssize_t nbytes; pipe(fildes); switch (fork()) { case -1: /* Handle error */ break; case 0: /* Child - reads from pipe */ close(fildes[1]); /* Write end is unused */ nbytes = read(fildes[0], buf, BSIZE); /* Get data from pipe */ /* At this point, a further read would see end of file... */ close(fildes[0]); /* Finished with pipe */ exit(EXIT_SUCCESS); default: /* Parent - writes to pipe */ close(fildes[0]); /* Read end is unused */ write(fildes[1], "Hello world\n", 12); /* Write data on pipe */ close(fildes[1]); /* Child will see EOF */ exit(EXIT_SUCCESS); } ]] _____________________________________________________________________________ COMMENT Enhancement Request Number 128 mtk-lists@gmx.net Bug in TC2-d2 popen() (rdvk# 128) {example for popen()} Fri, 18 Jul 2003 15:18:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (i've fixed up the example inline) _____________________________________________________________________________ Page: 1 Line: 28077 Section: popen() Problem: This is an EXAMPLE for the popen() man page. Line number references are to TC1. A pointer could also be added to this example on the pclose() page (line 27732). Action: Change "None" to the following: [Summary line] Using popen() to obtain a list of files from ls The following example demonstrates the use of popen() and pclose() to execute the command "ls *" in order to obtain a list of files in the current directory: #include ... FILE *fp; int status; char path[PATH_MAX]; fp = popen("ls *", "r"); if (fp == NULL) /* Handle error */; while (fgets(path, PATH_MAX, fp) != NULL) printf("%s", path); status = pclose(fp); if (status == -1) { /* Error reported by pclose() */ ... } else { /* Use macros described under wait() to inspect 'status' in order to determine success/failure of command executed by popen() */ ... } _____________________________________________________________________________ COMMENT Enhancement Request Number 129 mtk-lists@gmx.net Bug in TC2-d2 shm_open() (rdvk# 129) {example for shm_open()} Fri, 18 Jul 2003 17:03:55 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 41250 Section: shm_open() Problem: This is an EXAMPLE for the shm_open() man page. Line number references are to TC1. It could also be cited as an example for mmap() (line 25497). Action: Change "None" to the following: [Summary line] Creating and mapping a shared memory object The following code segment demonstrates the use of shm_open() to create a shared memory object which is then sized using ftruncate() before being mapped into the process address space using mmap(): #include #include ... #define MAX_LEN 10000 struct region { /* Defines "structure" of shared memory */ int len; char buf[MAX_LEN]; }; struct region *rptr; int fd; /* Create shared memory object and set its size */ fd = shm_open("/myregion", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR); if (fd == -1) /* Handle error */; if (ftruncate(fd, sizeof(struct region)) == -1) /* Handle error */; /* Map shared memory object */ rptr = mmap(NULL, sizeof(struct region), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (rptr == MAP_FAILED) /* Handle error */; /* Now we can refer to mapped region using fields of rptr, for example, rptr->len */ ... _____________________________________________________________________________ COMMENT Enhancement Request Number 130 mtk-lists@gmx.net Bug in TC2-d2 sigaction() (rdvk# 130) {example for sigaction} Fri, 18 Jul 2003 16:26:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 41807 Section: sigaction() Problem: This is an EXAMPLE for the sigaction() man page. Line number references are to TC1. Action: Change "None" to the following: [Summary line] Establishing a signal handler The following example demonstrates the use of sigaction to establish a handler for the SIGINT signal. #include static void handler(int signum) { /* Take appropriate actions for signal delivery */ } int main() { struct sigaction sa; sa.sa_handler = handler; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART; /* Restart functions if interrupted by handler */ if (sigaction(SIGINT, &sa, NULL) == -1) /* Handle error */; /* Further code */ } _____________________________________________________________________________ COMMENT Enhancement Request Number 131 mtk-lists@gmx.net Bug in TC2-d2 strptime() (rdvk# 131) {example for strptime()} Thu, 24 Jul 2003 10:06:47 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 44720 Section: strptime() Problem: This is an EXAMPLE for the strptime() man page. Line number references are to TC1. I thought the additional use of mktime() worthwhile since I myself recently was educated that in this scenario we must set tm_isdst if we then go on to call mktime(). Action: Change "None" to the following: [Summary line] Convert a data-plus-time string to broken-down time and then into seconds The following example demonstrates the use strptime() to convert a string into broken-down time. The broken-down time is then converted into seconds since the Epoch using mktime(). #include ... struct tm tm; time_t t; if (strptime("6 Dec 2001 12:33:45", "%d %b %Y %H:%M:%S", &tm) == NULL) /* Handle error */; printf("year: %d; month: %d; day: %d;\n", tm.tm_year, tm.tm_mon, tm.tm_mday); printf("hour: %d; minute: %d; second: %d\n", tm.tm_hour, tm.tm_min, tm.tm_sec); printf("week day: %d; year day: %d\n", tm.tm_wday, tm.tm_yday); tm.tm_isdst = -1; /* Not set by strptime(); tells mktime() to determine if daylight saving time is in effect */ t = mktime(&tm); if (t == -1) /* Handle error */; printf("seconds since the Epoch: %ld\n", (long) t); _____________________________________________________________________________ OBJECTION Enhancement Request Number 132 ajosey@opengroup.org Defect in XSH errno (rdvk# 132) {errno.iso.c.7.5} Thu, 24 Jul 2003 11:48:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to end of paragraph 2 The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified _____________________________________________________________________________ Page: 294 Line: 9523 Section: errno Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The errno man page misses some important information from the ISO C standard. This can lead to a misinterpretation of the requirements of when to set errno. Since this standard defers to ISO C we should add clarification text in the next TC. Action: Add to end of paragraph 2 "The value of errno may be set to non-zero by a function call whether or not there is an error, provided the use of errno is not documented for the function in IEEE Std 1003.1-2001" Alternately: Add to the DESCRIPTIONS of getgrgid, getgrnam, getpwnam, getpwuid, nice (note exact wording will depend on what wording is present at the moment) "The XXX() function shall not change the setting of errno if successful. Applications wishing to check for error situations should set errno to 0 before calling XXXX(). If errno is set to non-zero on return, an error occurred." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 133 rochkind@basepath.com Defect in XSH semget (rdvk# 133) {semget} Wed, 23 Jul 2003 20:24:28 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: shall not -> need not _____________________________________________________________________________ Page: 1269 Line: 39510 Section: semget Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Spec says "The data structure associated with each semaphore in the set shall not be initialized." Is this an intentional use of the word "shall?" How can it be implemented--what if the programming language system initializes all variables? How can conformance be checked? And, why would an application care? Action: Change wording to indicate that an implementation is not required to initialize. Perhaps this is as simple as changing "shall" to "may." _____________________________________________________________________________ COMMENT Enhancement Request Number 134 mtk-lists@gmx.net Bug in TC2-d2 fcntl() (rdvk# 134) {examples for fcntl()} Fri, 25 Jul 2003 13:38:30 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 10935 Section: fcntl() Problem: These are two EXAMPLES for the fcntl() man page. Line number references are to TC1. If the example needs to be shortened, then the code to remove the file lock could be cut, and the explanatory text suitably amended. Action: Change "None" to the following: [Summary] Locking and unlocking a file The following example demonstrates how to place a lock on bytes 100 to 109 of a file and then later remove it. F_SETLK is used to perform a non-blocking lock request so that the process does not have to wait if an incompatible is held by another process; instead the process can take some other action. #include #include #include #include int main(int argc, char *argv[]) { int fd; struct flock fl; fd = open("testfile", O_RDWR); if (fd == -1) /* Handle error */; /* Make a non-blocking request to place a write lock on bytes 100-109 of testfile */ fl.l_type = F_WRLCK; fl.l_whence = SEEK_SET; fl.l_start = 100; fl.l_len = 10; if (fcntl(fd, F_SETLK, &fl) == -1) { if (errno == EACCES || errno == EAGAIN) { printf("Already locked by another process\n"); /* We can't get the lock at the moment */ } else { /* Handle unexpected error */; } } else { /* Lock was granted... */ /* Perform I/O on bytes 100 to 109 of file */ /* Unlock the locked bytes */ fl.l_type = F_UNLCK; fl.l_whence = SEEK_SET; fl.l_start = 100; fl.l_len = 10; if (fcntl(fd, F_SETLK, &fl) == -1) /* Handle error */; } exit(EXIT_SUCCESS); } /* main */ [Summary] Setting the close-on-exec flag The following example demonstrates how to set the close on exec flag for the file descriptor fd. #include #include ... int flags; flags = fcntl(fd, F_GETFD); if (flags == -1) /* Handle error */; flags |= FD_CLOEXEC; if (fcntl(fd, F_SETFD, flags) == -1) /* Handle error */; _____________________________________________________________________________ COMMENT Enhancement Request Number 135 mtk-lists@gmx.net Bug in TC2-d2 killpg() (rdvk# 135) {example for killpg()} Fri, 25 Jul 2003 12:40:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take it as it is below, but if someone wants to modify this to use sigaction() _____________________________________________________________________________ Page: 1 Line: 22253 Section: killpg() Problem: This is an EXAMPLE for the killpg() man page. Line number references are to TC1. Action: Change "None" to the following: [Summary] Sending a signal to all other members of a process group The following example shows how the calling process could send a signal to all other members of its process group. To prevent itself from receiving the signal it first makes itself immune to the signal by ignoring it. #include #include ... if (signal(SIGUSR1, SIG_IGN) == SIG_ERR) /* Handle error */; if (killpg(getpgrp(), SIGUSR1) == -1) /* Handle error */; _____________________________________________________________________________ OBJECTION Enhancement Request Number 136 drepper@redhat.com Defect in XSH pthread_create() (rdvk# 136) {ud-ptcreate} Tue, 11 Feb 2003 01:30:57 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1046 Line: 32866 Section: pthread_create() Problem: Defect code : 1. Error The error section of pthread_create() currently states: [EINVAL] The value specified by attr is invalid. That's a very vague description. I could not agree to the requirement that pthread_create() has to be able to detect stray pointers passed for this parameter. Just like in the rest of the specification, it is the programmers responsibility to pass NULL or a valid pointer to a pthread_attr_t object. What I instead think the error can require is that if a pthread_attr_t object with invalid content is passed to pthread_create() an error is returned. Note: 'value' is very vague. What value? But then again: maybe the pthread_attr_t object contains a pointer which, if corrupted somehow, can take on any value. For this reasons I think this error should be made optional. Action: Remove line 32866 and add after line 32868: The pthread_create() function may fail if: [EINVAL] The attributes specified by attr are invalid. _____________________________________________________________________________ OBJECTION Enhancement Request Number 137 don.cragun@sun.com Defect in XSH tmpnam (rdvk# 137) {dwc-tmpnam()20030801} Fri, 1 Aug 2003 21:37:13 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: Go with first choice _____________________________________________________________________________ Page: 1533 Line: 47433-47434 Section: tmpnam Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The description of tmpnam() on XSH6, P1533, L47433-47434 says "The implementation shall behave as if no function defined in this volume of IEEE Std 1003.1-2001 calls tmpnam(), but the description of tempnam() on XSH6, P1513, L46807 says "implementations of tempnam() may use tmpnam() internally". This inconsistency does not violate the C standard (C does not include a definition of tempnam()), it is just an inconsistency in internal POSIX.1-2001 requirements. Action: Change: "The implementation shall behave as if no function defined in this volume of IEEE Std 1003.1-2001 calls tmpnam()." on P1533, L47433-47434 to either say: "The implementation shall behave as if no function defined in this volume of IEEE Std 1003.1-2001 except tempnam() calls tmpnam()." or to say: "The implementation shall behave as if no function defined in ISO C calls tmpnam()." _____________________________________________________________________________ COMMENT Enhancement Request Number 138 ajosey@opengroup.org Defect in XSH abort (rdvk# 138) {impldefined} Fri, 8 Aug 2003 14:07:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The change here was erroneous "Catching the signal is intended to provide the application writer with a portable means to abort processing, free from possible interference from any implementation-supplied functions." also fix dlopen page ------ I do not think this is inline with the terminology definition Action:AJ Search on old implementation-provided in XSH5 and look for the changes abort in XSH 5 - See above: XBD Chapter 8 Environment Variables NLSPATH was "implementation-dependent" in Issue 5 which says that "an implementor normally documents the behavior" implementation-specified occurs once in XSH5 in dlopen (became implementation-defined in XSH6) XSH5 wording: "If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, then an implementation-specified default behaviour will be applied." I believe this should change to "If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, then an unspecified default behaviour is applied." or "If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, then the default behaviour is unspecified." implementation-dependent was also used in XSH5 encrypt, LOGIN_PROCESS member of ut_type member for endutxent, and many many places. As noted above this does require documentation and appears the equiv of implementation-defined. _____________________________________________________________________________ Page: 92 Line: 3559 Section: abort Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The application-usage uses the term "implementation-defined" in "Catching the signal is intended to provide the application writer with a portable means to abort processing, free from possible interference from any implementation-defined functions." I do not think this is inline with the terminology definition and would be better rephrased as "any implementation-provided functions" perhaps? Action: Change from: "implementation-defined" To: "implementation-provided" _____________________________________________________________________________ COMMENT Enhancement Request Number 139 ajosey@opengroup.org Defect in XSH alarm (rdvk# 139) {impldefined} Fri, 8 Aug 2003 14:21:31 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 119 Line: 4375 Section: alarm Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The rationale uses the term "implementation-defined" in "In some implementations, including 4.3 BSD, very large values of the seconds argument are silently rounded down to an implementation-defined maximum value" I do not think this is inline with the terminology definition and would be better rephrased as "any implementation-specific maximum value" perhaps? Action: Change from: "implementation-defined" To: "implementation-specific" _____________________________________________________________________________ COMMENT Enhancement Request Number 140 ajosey@opengroup.org Defect in XSH basename (rdvk# 140) {aj.142.8.8.2003} Fri, 8 Aug 2003 14:51:13 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 142 Line: 5007 Section: basename Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The second paragraph is unclear about what the "string" is. I assume its the string pointed to by the "path" argument. It should be more clearly stated. Action: Change from: "If the string consists entirely of the '/' character" To: "If the string pointed to by /path/ consists entirely of the '/' character..." Change from: "If the string is exactly "//", it is ...." To: "If the string pointed to by /path/ is exactly "//", it is..." _____________________________________________________________________________ COMMENT Enhancement Request Number 141 ajosey@opengroup.org Defect in XSH fdopen (rdvk# 141) {fdopen.impldefined} Mon, 11 Aug 2003 08:55:28 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 343 Line: 11246 Section: fdopen Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The RATIONALE for fdopen states "The file descriptor may have been obtained from open(), creat(), pipe(), dup(), or fcntl(); inherited through fork() or exec; or perhaps obtained by implementation-defined means, such as the 4.3 BSD socket() call." This seems to predate the inclusion of sockets into the specification. Its unclear what value the sentence has, and an attempt is made below to update it and generalize it. Action: Change to: The file descriptor may have been obtained from open(), creat(), pipe(), dup(), fcntl() or socket(); inherited through fork(), posix_spawn() or exec; or perhaps obtained by other means. _____________________________________________________________________________ OBJECTION Enhancement Request Number 142 don.cragun@sun.com Defect in XSH freopen (rdvk# 142) {dwc-freopen.20030806} Thu, 7 Aug 2003 00:00:42 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Don had checked with the chair of the C standards committee and he had agreed with the proposed change. "If filename is a null pointer, the freopen() function shall attempt to change the mode of the stream to that specified by mode, as if the name of the file currently associated with the stream had been used. In this case, the file descriptor associated with the stream need not be closed if the call to freopen() succeeds. It is implementation-defined which changes of mode are permitted (if any) and under what circumstances". And add a shall fail error [EBADF] The file descriptor underlying the stream is not a valid file descriptor when filename is a null pointer. and add a may fail error [EBADF] The mode with which the file descriptor underlying the stream was opened does not support the requested mode when filename is a null pointer. _____________________________________________________________________________ Page: 430 Line: 14134-14144 Section: freopen Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The ability to pass a null pointer to freopen() as a filename operand was added to C99 and inherited by this standard from there. In this standard P430, L14141-14144 (as well as in the C standard), it says: "If filename is a null pointer, the freopen() function shall attempt to change the mode of the stream to that specified by mode, as if the name of the file currently associated with the stream had been used. It is implementation-defined which changes of mode are permitted (if any) and under what circumstances". The paragraph in this standard on P430, L14134-14136: "The freopen() function shall first attempt to flush the stream and close any file descriptor associated with stream. Failure to flush or close the file descriptor successfully shall be ignored. The error and end-of-file indicators for the stream shall be cleared." corresponds to the last paragraph in the description of freopen() in the C Standard (subclause 7.19.5.6, paragraph 4): "The freopen function first attempts to close any file that is associated with the specified stream. Failure to close the file is ignored. The error and end-of-file indicators for the stream are cleared." Note that in the C Standard, there are no file descriptors only files referenced by the FILE * returned by fopen() and freopen(). Note also that in the C Standard, this paragraph about closing the file associated with the specified stream follows the paragraph saying that when filename is a null pointer, it is implementation-defined which changes of mode are permitted (if any) and under what circumstances. It is my belief that a perfectly reasonable implementation of freopen(NULL, mode, stream) would allow the stream (or FILE *) to be reinitialized without actually closing the underlying file descriptor. (Given POSIX semantics of destroying a file whose last link has been removed from the filesystem on last close, this is absolutely necessary if freopen() is to succeed on such files. If the intent were that the underlying file descriptor actually had to be closed, there would be no reason to have implementation-defined behavior for mode changes; implementations would essentially be required to fclose(stream) and fopen(name_of_file_previously_associated_with_stream, mode) and be sure that the returned stream was the original stream pointer. If the fopen() succeeded, you would have the requested mode with no implementation-defined behavior required. If the fopen() failed, the freopen() would fail! In either case, the stream has essentially been closed and reopened whether the underlying file descriptor is closed or not.) Unfortunately, at least one test suite has been written assuming that the requirement to close the file descriptor associated with the stream applies even if the filename pointer is null. We need an interpretation or clarification of the standard to make this clear. Action: Add a sentence to the paragraph on P430, L14141-14144 so that the updated paragraph is: "If filename is a null pointer, the freopen() function shall attempt to change the mode of the stream to that specified by mode, as if the name of the file currently associated with the stream had been used. In this case, the file descriptor associated with the stream need not be closed if the call to freopen() succeeds. It is implementation-defined which changes of mode are permitted (if any) and under what circumstances". Since other parts of the description of freopen() that talk about the file descriptor (which is not mentioned in the C Standard) are not CX shaded, I don't know if this new sentence should be CX shaded or left unshaded. The new sentence does not change any C Standard required behavior. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 143 ajosey@opengroup.org Defect in XSH fsync (rdvk# 143) {fsync.impldefined} Mon, 11 Aug 2003 10:49:43 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 452 Line: 14896 Section: fsync Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The DESCRIPTION states: "The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes in an implementation-defined manner." This reads poorly and should be split into two sentences. Action: Change to: "The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes. The nature of the transfer is implementation-defined." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 144 ajosey@opengroup.org Defect in XSH kill (rdvk# 144) {kill.impldefined} Mon, 11 Aug 2003 11:32:04 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 669 Line: 22175 Section: kill Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The RATIONALE states: "The implementation-defined processes to which a signal cannot be sent.." but the DESCRIPTION talks of "unspecified set of system processes" Action: Change from: "The implementation-defined processes to which a signal cannot be sent.." to "The unspecified processes to which a signal cannot be sent.." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 145 ajosey@opengroup.org Defect in XSH poll (rdvk# 145) {typo} Fri, 8 Aug 2003 09:46:08 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 860 Line: 27998 Section: poll Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Two lines of the example are indented in when they should not be Action: Change from: /* Open STREAMS device. */ fds[0].fd = open("/dev/dev0", ...); fds[1].fd = open("/dev/dev1", ...); fds[0].events = POLLOUT | POLLWRBAND; fds[1].events = POLLOUT | POLLWRBAND; to: /* Open STREAMS device. */ fds[0].fd = open("/dev/dev0", ...); fds[1].fd = open("/dev/dev1", ...); fds[0].events = POLLOUT | POLLWRBAND; fds[1].events = POLLOUT | POLLWRBAND; _____________________________________________________________________________ OBJECTION Enhancement Request Number 146 drepper@redhat.com Defect in XSH posix_fadvise() (rdvk# 146) {ud-fadvise} Fri, 8 Aug 2003 10:44:23 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept the proposal for posix_fadvise and also the following for posix_fallocate() which has the same problem. Change XSH p866 line 28177 with int posix_fallocate(int fd, off_t offset, off_t len); Change XBD p224 line 7898 with int posix_fallocate(int, off_t, off_t); (CROSSVOL to XBD headers also) _____________________________________________________________________________ Page: 864 Line: 28122 Section: posix_fadvise() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The prototype for posix_fadvise() today is: int posix_fadvise(int fd, off_t offset, size_t len, int advice); The problem is the type of the 'len' parameter. This is no value related to any memory object, it's the length of the affected area on disk. This is especially problematic for platforms implementing the LFS extension. On a 32-bit system, giving advise for a multi-terabyte file would require many calls. Action: Change XSH 864, l 28122 to: int posix_fadvise(int fd, off_t offset, off_t len, int advice); Change XBD 223, l 7897 to: ADV int posix_fadvise(int, off_t, off_t, int); _____________________________________________________________________________ COMMENT Enhancement Request Number 147 loic-dev@gmx.net Defect in XSH pthread_attr_destroy (rdvk# 147) {pthread_attr_destroy} Mon, 11 Aug 2003 13:22:22 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 981 Line: 31291 Section: pthread_attr_destroy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_destroy() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. ______________________________________________________________________________ COMMENT Enhancement Request Number 148 loic-dev@gmx.net Defect in XSH pthread_attr_destroy (rdvk# 148) {pthread_attr_init, issue EBUSY} Mon, 11 Aug 2003 16:09:25 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 981 Line: 31291 Section: pthread_attr_destroy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission References are given against TC1. In lines 31286-31287, it is said that: | results are undefined if pthread_attr_init() is called specifying an | already initialized attr attributes object. However, the standard doesn't define any optional checking for this error. Action: At l31291-31294 (ERRORS), add: The pthread_attr_init() may fail if: [EBUSY] The implementation has detected an attempt to reinitialize the thread attribute referenced by attr, a previously initialized, but not yet destroyed, thread attribute. _____________________________________________________________________________ COMMENT Enhancement Request Number 149 loic-dev@gmx.net Defect in XSH pthread_attr_getdetachstate (rdvk# 149) {pthread_attr_getdetachstate} Mon, 11 Aug 2003 13:26:52 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 984 Line: 31402 Section: pthread_attr_getdetachstate Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getdetachstate() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setdetachstate() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. ______________________________________________________________________________ OBJECTION Enhancement Request Number 150 loic-dev@gmx.net Defect in XSH pthread_attr_getguardsize (rdvk# 150) {pthread_attr_getguardsize} Mon, 11 Aug 2003 13:54:49 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 986 Line: 31459 Section: pthread_attr_getguardsize Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. For pthread_attr_{get|set}guardsize(), the standard specifies a "shall fail" for the validation of attr. As explained by David Butenhof on austin-group-l: | Generally, no validation of attr should be "shall fail", because it's | impractical (if not impossible) to provide a real guarantee that an | attributes object is uncorrupted and in every respect "valid" We suggest to weaken the "shall fail" by a "may fail". Action: - Remove line 31461. - Add: The pthread_attr_getguardsize() and pthread_attr_setguardsize may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. ______________________________________________________________________________ COMMENT Enhancement Request Number 151 loic-dev@gmx.net Defect in XSH pthread_attr_getinheritsched (rdvk# 151) {pthread_attr_getinheritsched, issue 2/2}Mon, 11 Aug 2003 15:18:02 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 988 Line: 31500 Section: pthread_attr_getinheritsched Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission References are given against TC1. That's probably a penny, but it is not said explicetely that both PTHREAD_INHERIT_SCHED and PTHREAD_EXPLICIT_SCHED shall be supported. Furthermore, since we don't see any other reasonable values for inheritsched, I suggest to restrict the implementation to these 2 values. Action: At line 31500, add: "The supported values of inheritsched shall be:" [[Note for the reviewers: A possible formulation, if we want to allow implementations defined inheritsched values is: "The supported values of inheritsched shall include:" ]] __________________________________________________________________________ COMMENT Enhancement Request Number 152 loic-dev@gmx.net Defect in XSH pthread_attr_getinheritsched (rdvk# 152) {pthread_attr_getinheritsched} Mon, 11 Aug 2003 14:01:29 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 988 Line: 31515 Section: pthread_attr_getinheritsched Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getinheritsched() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setinheritsched() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. _____________________________________________________________________________ COMMENT Enhancement Request Number 153 loic-dev@gmx.net Defect in XSH pthread_attr_getinheritsched (rdvk# 153) {pthread_attr_setinheritsched} Mon, 11 Aug 2003 14:34:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: There was a feeling that some implementations may be returning ENOTSUP We were able to obtain consensus, so we decided to reject the proposal. ______________________________________________________________________________ Page: 988 Line: 31518 Section: pthread_attr_getinheritsched Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required References are given against TC1. At line 31518, the standard define a possible ENOTSUP error for pthread_setinheritsched() when "an attempt was made to set the attribute to an unsupported value." As explained by David Butenhof on austin-group-l (Thr #5856): | I think we ought to remove the ENOTSUP if we're cleaning up -- unless | someone can recall why it was there and offer some rationale. ;-) | PTHREAD_INHERIT_SCHED and PTHREAD_EXPLICIT_SCHED must be supported. So | ENOTSUP could apply only to non-standard additional inheritsched | codes. (And I still can't imagine how any could be reasonable and | valid; but nevermind that.) This error code presupposes that it's OK | for an implementation to define nonstandard codes that it doesn't | support. Dumb. But even with that... the standard never precludes | adding additional error codes for additional conditions not covered | by the standard. Without extensions, or even with reasonable | extensions, ENOTSUP has no purpose here. Action: remove the line 31518 _______________________________________________________________________ COMMENT Enhancement Request Number 154 loic-dev@gmx.net Defect in XSH pthread_attr_getschedparam (rdvk# 154) {pthread_attr_getschedparam} Mon, 11 Aug 2003 14:05:13 +0100 (BST) ____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ____________________________________________________________________________ Page: 990 Line: 31567 Section: pthread_attr_getschedparam Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getschedparam() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setschedparam() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. _____________________________________________________________________________ COMMENT Enhancement Request Number 155 loic-dev@gmx.net Defect in XSH pthread_attr_getschedpolicy (rdvk# 155) {pthread_attr_getschedpolicy} Mon, 11 Aug 2003 14:08:17 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 992 Line: 31612 Section: pthread_attr_getschedpolicy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getschedpolicy() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setschedpolicy() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. __________________________________________________________________________ OBJECTION Enhancement Request Number 156 loic-dev@gmx.net Defect in XSH pthread_attr_getscope (rdvk# 156) {pthread_attr_getscope, issue 2/2} Mon, 11 Aug 2003 14:57:41 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The feeling was that the standard is correct as it is, it is a statement of fact . The requirements for the header is stated in pthread.h as shall, and pthread.h is in the function SYNOPSIS. There are many similar descriptions elsewhere. _____________________________________________________________________________ Page: 994 Line: 31655 Section: pthread_attr_getscope Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required References are given against TC1. At lines 31655-31656, it is said: | The symbols PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS are defined | in the header. >From the context (lines 31653-31655), it is not clear that _BOTH_ symbols are defined in . As explained by David Butenhof on austin-group-l (see Thr #5856): | POSIX says that "The symbols PTHREAD_SCOPE_SYSTEM and | PTHREAD_SCOPE_PROCESS shall be defined" while XSH says weakly | that they "are defined". This should be fixed. Action: Change lines 31655-31656: The symbols PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS are defined in the header. To: Independantly of the contentionscope supported, both symbols PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS shall be defined in the header. _____________________________________________________________________________ COMMENT Enhancement Request Number 157 loic-dev@gmx.net Defect in XSH pthread_attr_getscope (rdvk# 157) {pthread_attr_getscope} Mon, 11 Aug 2003 14:10:10 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 994 Line: 31660 Section: pthread_attr_getscope Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getscope() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setscope() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. _____________________________________________________________________________ COMMENT Enhancement Request Number 158 loic-dev@gmx.net Defect in XSH pthread_attr_getstack (rdvk# 158) {pthread_attr_getstack} Mon, 11 Aug 2003 14:12:11 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 996 Line: 31771 Section: pthread_attr_getstack Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getstack() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setstack() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. ______________________________________________________________________________ COMMENT Enhancement Request Number 159 loic-dev@gmx.net Defect in XSH pthread_attr_getstackaddr (rdvk# 159) {pthread_attr_getstackaddr} Mon, 11 Aug 2003 14:18:30 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 998 Line: 31760 Section: pthread_attr_getstackaddr Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getstackaddr() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setstackaddr() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. ______________________________________________________________________________ COMMENT Enhancement Request Number 160 loic-dev@gmx.net Defect in XSH pthread_attr_getstacksize (rdvk# 160) {pthread_attr_getstacksize} Mon, 11 Aug 2003 14:21:14 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ______________________________________________________________________________ Page: 1000 Line: 31812 Section: pthread_attr_getstacksize Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Reference are given against TC1. They are inconsistencies in the errors handling between the pthread_attr_* XSH. In particular, the standard doesn't specify any optional test for checking when attr refers to an initialized thread attribute object. Action: Add: The pthread_attr_getstacksize() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. The pthread_attr_setstacksize() may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. ____________________________________________________________________________ COMMENT Enhancement Request Number 161 loic-dev@gmx.net Defect in XSH pthread_barrierattr_destroy (rdvk# 161) {pthread_barrierattr_init, issue EBUSY} Mon, 11 Aug 2003 16:15:53 +0100 (BST) ____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The feeling was that this proposed error was based on "undefined results" in the DESCRIPTION, and that really means that no error or behavior is defined, an implementation might invoke foomatic debugger or some other thing, EFAULT might be just as valid as EBUSY. If we were to add EBUSY, then consequently the "undefined results" language would also need changing. __________________________________________________________________________ Page: 1016 Line: 32061 Section: pthread_barrierattr_destroy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission References are given against TC1. In lines 32053-32054, it is said that: | results are undefined if pthread_barrierattr_init() is called | specifying an already initialized attr attributes object. However, the standard doesn't define any optional checking for this error. Action: At l32061-32066 ('ERRORS), add: The pthread_barrierattr_init() may fail if: [EBUSY] The implementation has detected an attempt to reinitialize the barrier attribute object referenced by attr, a previously initialized, but not yet destroyed, attribute object. _____________________________________________________________________________ COMMENT Enhancement Request Number 162 loic-dev@gmx.net Defect in XSH pthread_condattr_destroy (rdvk# 162) {pthread_condattr_init, issue EBUSY} Mon, 11 Aug 2003 16:20:08 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: similar cases to 161 _____________________________________________________________________________ Page: 1041 Line: 32853 Section: pthread_condattr_destroy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission References are given against TC1. In lines 32841-32842, it is said that: | results are undefined if pthread_condattr_init() is called | specifying an already initialized attr attributes object. However, the standard doesn't define any optional checking for this error. Action: At l32853-32858 (ERRORS), add: The pthread_condattr_init() may fail if: [EBUSY] The implementation has detected an attempt to reinitialize the condition variable attribute object referenced by attr, a previously initialized, but not yet destroyed, attribute object. ______________________________________________________________________________ COMMENT Enhancement Request Number 163 loic-dev@gmx.net Defect in XSH pthread_mutexattr_destroy (rdvk# 21) {pthread_mutexattr_init, issue EBUSY} Mon, 11 Aug 2003 16:22:39 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: similar case to 161 _____________________________________________________________________________ Page: 1091 Line: 34280 Section: pthread_mutexattr_destroy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission References are given against TC1. In lines 34272-34273, it is said that: | results are undefined if pthread_mutexattr_init() is called | specifying an already initialized attr attributes object. However, the standard doesn't define any optional checking for this error. Action: At l34280-34285 (ERRORS), add: The pthread_mutexattr_init() may fail if: [EBUSY] The implementation has detected an attempt to reinitialize the mutex attribute object referenced by attr, a previously initialized, but not yet destroyed, attribute object. ______________________________________________________________________________ COMMENT Enhancement Request Number 164 loic-dev@gmx.net Defect in XSH pthread_rwlockattr_destroy (rdvk# 164) {pthread_rwlockattr_init, issue EBUSY} Mon, 11 Aug 2003 16:27:09 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: similar to 161 ______________________________________________________________________________ Page: 1125 Line: 35289 Section: pthread_rwlockattr_destroy Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission References are given against TC1. In lines 35281-35282, it is said that: | results are undefined if pthread_rwlockattr_init() is called | specifying an already initialized attr attributes object. However, the standard doesn't define any optional checking for this error. Action: At l35289-35294 (ERRORS), add: The pthread_rwlockattr_init() may fail if: [EBUSY] The implementation has detected an attempt to reinitialize the read-write lock attribute object referenced by attr, a previously initialized, but not yet destroyed, attribute object. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 165 ajosey@opengroup.org Defect in XSH read (rdvk# 165) {typo} Fri, 8 Aug 2003 09:43:37 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1177 Line: 36652 Section: read Problem: Edition of Specification (Year): 2003 Defect code : 1. Error There is a typo on p 1177, line 36652 Action: Change "that buffers read()ss actually" to "that buffers read()s actually" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 166 loic-dev@gmx.net Defect in XSH write (rdvk# 166) {write} Mon, 11 Aug 2003 11:22:46 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change To: A write was attempted on a socket that is shut down for writing, or is no longer connected. In the latter case, if the socket is of type SOCK_STREAM, a SIGPIPE signal shall also be sent to the thread. _____________________________________________________________________________ Page: 51173 Line: 1659 Section: write Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Reference are given against TC1. At line 51171-51173 it is stated that: The write() function shall fail if: [EPIPE] A write was attempted on a socket that is shut down for writing, or is no longer connected. In the latter case, if the socket is of type SOCK_STREAM, the SIGPIPE signal is generated to the calling process. As discussed on c.p.t. (see thread "signals, threads, SIGPIPE, sigpending (fun!)"), SIGPIPE should be thread-oriented, and not process-oriented. Note that, some "modern unix" still treat SIGPIPE as a process oriented signal. In fact, SIGPIPE is delivered to the thread that call write() as expected. But when the thread is scheduled out, some implementations chose to "move" the signal to the to-be-scheduled thread, since they consider that the signal should be delivered ASAP. Action: replace "process" by "thread". _____________________________________________________________________________ OBJECTION Enhancement Request Number 167 lee.damico@Sun.com Defect in XSH 2.2.2 The Name Space (rdvk# 167) {ld-1} Thu, 14 Aug 2003 00:18:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Section 2.2.2, Page 15, Line 583 Add the following "Symbols defined in the standard that use the reserved prefix _POSIX_ may be visible in any header defined by the standard." And on Page 19 line 713 change item 1 to "1. With the exception of identifiers beginning with the prefix _POSIX_, all identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use by the implementation." Rationale: Implementations have previously been free to have symbols with the prefix _POSIX_ visible in any header. _____________________________________________________________________________ Page: 15 Line: 579-583 Section: 2.2.2 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The 2003 Edition of the Systems Interface, Issue 6, Volume 1 removed the reserved prefixes for POSIX_, _POSIX_, posix_ that were previously listed on page 17, line 651, under "ANY header". Though we believe the intent was to remove ambiguity regarding the inclusion of symbols prefixed by POSIX_, _POSIX_, and posix_, but NOT defined by the standard, the end result appears to be that symbols specified by the standard and prefixed with these names are only allowed in the headers where they are defined. Where this becomes an issue specifically is for the _POSIX_ prefix. Visibility of symbols with an underbar and upper case letter have always been allowed in any of the headers defined by the standard. This is clarified on page 19, lines 713-714. Now, it appears that there is an exception, that is when a symbol is prefixed by _POSIX_ regardless of whether or not it is defined by the standard. We believe the intent was not to disallow visibility of those symbols defined by the standard, but instead, to restrict the namespace for _POSIX_ to that specified by the standard. The suggested updates clarify what is and is not allowed. Action: Section 2.2.2, Page 15, Line 583 Add the following sentence: Symbols defined in the standard that use the reserved prefixes posix_, POSIX_ or _POSIX_ may be visible in any header defined by the standard. Section 2.2.2, Page 19, Lines 713 and 714 Replace the sentence with: 1. With the exception of identifiers beginning with _POSIX_, all identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use by the implementation.