XSH D3R Aardvark Reports Austin-394 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Sep 10, 2007 Aardvark Summary Table ______________________ ERN 1 Accept ERN 2 Accept as marked ERN 3 Accept as marked ERN 4 Accept ERN 5 Accept ERN 6 Accept ERN 7 Accept as marked ERN 8 Accept as marked ERN 9 Accept as marked ERN 10 Accept as marked ERN 11 Accept as marked ERN 12 Accept as marked ERN 13 Accept ERN 14 Accept ERN 15 Accept ERN 16 Accept as marked ERN 17 Accept ERN 18 Accept as marked ERN 19 Accept ERN 20 Accept ERN 21 Accept ERN 22 Accept ERN 23 Accept as marked ERN 24 Accept as marked ERN 25 Accept ERN 26 Duplicate of 25 ERN 27 Accept as marked ERN 28 Accept as marked ERN 29 Accept ERN 30 Accept ERN 31 Accept ERN 32 Accept as marked ERN 33 Accept ERN 34 Accept as marked ERN 35 Accept ERN 36 Accept as marked ERN 37 Accept ERN 38 Duplicate of 37 ERN 39 Accept ERN 40 Accept as marked ERN 41 Accept as marked ERN 42 Accept ERN 43 Accept as marked ERN 44 Accept ERN 45 Accept ERN 46 Accept ERN 47 Accept ERN 48 Accept ERN 49 Accept ERN 50 Accept as marked ERN 51 Accept ERN 52 Accept ERN 53 Accept ERN 54 Accept ERN 55 Accept as marked _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 gwc:xxxxxxxxxxxxx Bug in XSHd3 page headers (rdvk# 7) [gwc page headers] Mon, 16 Jul 2007 11:59:52 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Some page headers have the wrong function names. The incorrect names are always the one from the previous page, and if the function description takes up more than one page the header of the next page has the right name, so this appears to be related to premature page throwing rather than incorrect names in the source. Action: page 646: clock_getres -> clock_nanosleep page 758: exit -> exp page 939: futimens -> fwide page 1259: mkdtemp -> mkfifo _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 ebb9:xxxxxxx Bug in XSHd3 restrict (rdvk# 46) {ebb.restrict} Mon, 23 Jul 2007 17:11:46 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At line 11005 (XBD signal.h), change: void psiginfo(siginfo_t *, const char *); to: void psiginfo(const siginfo_t *, const char *); At line 11634 (XBD stdio.h), change: int dprintf(int, const char *, ...) to: int dprintf(int, const char *restrict, ...) [Note - if vdprintf is added, as is the subject aardvark XSHd3 #4 (ERN 32), it would also need restrict.] At line 11666-11667 (XBD stdio.h), change: ssize_t getdelim(char **, size_t *, int, FILE *); ssize_t getline(char **, size_t *, FILE *); to: ssize_t getdelim(char **restrict, size_t *restrict, int, FILE *restrict); ssize_t getline(char **restrict, size_t *restrict, FILE *restrict); At lines 15287-15288 (XBD wchar.h), change: size_t wcsnrtombs(char *, const wchar_t **, size_t, size_t, mbstate_t *); to: size_t wcsnrtombs(char *restrict, const wchar_t **restrict, size_t, size_t, mbstate_t *restrict); At lines 24357 (XSH dprintf) and 29233 (XSH fprintf), change: int dprintf(int filedes, const char *format, ...); to: int dprintf(int filedes, const char *restrict format, ...); [Note - if vdprintf is added, as is the subject aardvark XSHd3 #4 (ERN 32), it would also need restrict.] At lines 33041-33043 (XSH getdelim) and 33734 (XSH getline), change: ssize_t getdelim(char **lineptr, size_t *n, int delimiter, FILE *stream); ssize_t getline(char **lineptr, size_t *n, FILE *stream); to: ssize_t getdelim(char **restrict lineptr, size_t *restrict n, int delimiter, FILE *restrict stream); ssize_t getline(char **restrict lineptr, size_t *restrict n, FILE *restrict stream); At line 48532 (XSH psiginfo), change: void psiginfo(siginfo_t *pinfo, const char *message); to: void psiginfo(const siginfo_t *, const char *message); At lines 68259-68260 (XSH wcsnrtombs) and 68329-68330 (XSH wcsrtombs), change: size_t wcsnrtombs(char *dst, const wchar_t **src, size_t nwc, size_t len, mbstate_t *ps); to: size_t wcsnrtombs(char *restrict dst, const wchar_t **restrict src, size_t nwc, size_t len, mbstate_t *restrict ps); _____________________________________________________________________________ Page: 0 Line: 0 Section: restrict Problem: Some of the functions added in API Set 1 are missing restrict modifiers. Since not all of these functions were modified in draft 3, this should be considered in light of consistency with the rest of the standard. Note also that fmemopen, also added in Set 1, does use restrict). The proposal does not modify alphasort (and is careful in the modification of scandir), on the grounds that comparing a struct dirent with itself should be allowed (and returns 0). The fact that glibc declares alphasort as taking const void* instead of const struct dirent** is unrelated to this aardvark, but is worth considering as well, as is the question as whether alphasort can/should set errno to EILSEQ in some locales. The proposal does not modify fexecve, on the grounds that none of the other exec functions use restrict. The proposal does not modify linkat, on the grounds that link also does not use restrict. The proposal does not modify renameat, on the grounds that rename also does not use restrict. The proposal does not modify symlinkat, on the grounds that symlink also does not use restrict. Action: At lines 7472-7475 (XBD dirent.h), change: int scandir(const char *, struct dirent ***, int (*)(const struct dirent *), int (*)(const struct dirent **, const struct dirent **)); to: int scandir(const char *restrict, struct dirent ***restrict, int (*)(const struct dirent *), int (*)(const struct dirent **, const struct dirent **)); At line 11005 (XBD signal.h), change: void psiginfo(siginfo_t *, const char *); to: void psiginfo(siginfo_t *restrict, const char *restrict); At line 11634 (XBD stdio.h), change: int dprintf(int, const char *, ...) to: int dprintf(int, const char *restrict, ...) [Note - if vdprintf is added, as is the subject aardvark XSHd3 #4 (ERN 32), it would also need restrict.] At line 11666-11667 (XBD stdio.h), change: ssize_t getdelim(char **, size_t *, int, FILE *); ssize_t getline(char **, size_t *, FILE *); to: ssize_t getdelim(char **restrict, size_t *restrict, int, FILE *restrict); ssize_t getline(char **restrict, size_t *restrict, FILE *restrict); At line 11669 (XBD stdio.h), change: FILE *open_memstream(char **, size_t *); to: FILE *open_memstream(char **restrict, size_t *restrict); At line 15246 (XBD wchar.h), change: FILE *open_wmemstream(wchar_t **, size_t *); to: FILE *open_wmemstream(wchar_t **restrict, size_t *restrict); At lines 15287-15288 (XBD wchar.h), change: size_t wcsnrtombs(char *, const wchar_t **, size_t, size_t, mbstate_t *); to: size_t wcsnrtombs(char *restrict, const wchar_t **restrict, size_t, size_t, mbstate_t *restrict); At lines 19886-19888 (XSH alphasort) and 56347-56349 (XSH scandir), change: int scandir(const char *dir, struct dirent ***namelist, int (*sel)(const struct dirent *), int (*compar)(const struct dirent **, const struct dirent **)); to: int scandir(const char *restrict dir, struct dirent ***restrict namelist, int (*sel)(const struct dirent *), int (*compar)(const struct dirent **, const struct dirent **)); At lines 24357 (XSH dprintf) and 29233 (XSH fprintf), change: int dprintf(int filedes, const char *format, ...); to: int dprintf(int filedes, const char *restrict format, ...); [Note - if vdprintf is added, as is the subject aardvark XSHd3 #4 (ERN 32), it would also need restrict.] At lines 33041-33043 (XSH getdelim) and 33734 (XSH getline), change: ssize_t getdelim(char **lineptr, size_t *n, int delimiter, FILE *stream); ssize_t getline(char **lineptr, size_t *n, FILE *stream); to: ssize_t getdelim(char **restrict lineptr, size_t *restrict n, int delimiter, FILE *restrict stream); ssize_t getline(char **restrict lineptr, size_t *restrict n, FILE *restrict stream); At lines 44767, 44769 (XSH open_memstream) and 44846 (XSH open_wmemstream), change: FILE *open_memstream(char **bufp, size_t *sizep); FILE *open_wmemstream(wchar_t **bufp, size_t *sizep); to: FILE *open_memstream(char **restrict bufp, size_t *restrict sizep); FILE *open_wmemstream(wchar_t **restrict bufp, size_t *restrict sizep); At line 48532 (XSH psiginfo), change: void psiginfo(siginfo_t *pinfo, const char *message); to: void psiginfo(siginfo_t *restrict pinfo, const char *restrict message); At lines 68259-68260 (XSH wcsnrtombs) and 68329-68330 (XSH wcsrtombs), change: size_t wcsnrtombs(char *dst, const wchar_t **src, size_t nwc, size_t len, mbstate_t *ps); to: size_t wcsnrtombs(char *restrict dst, const wchar_t **restrict src, size_t nwc, size_t len, mbstate_t *restrict ps); _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 mh-austin:xxxxxx Bug in XSHd3 sys/socket.h (rdvk# 29) [mh2007d301] Tue, 10 Jul 2007 07:58:14 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change to XBD Change "The MSG_NOSIGNAL() macro" to "The MSG_NOSIGNAL symbolic constant" and remove italics. _____________________________________________________________________________ Page: 369 Line: 12784 Section: sys/socket.h Problem: Because MSG_NOSIGNAL does not accept arguments, it should not be followed by "()" or be in italics (typographical conventions, page xxxv line 1468). It should match the corresponding text on pages 1803, 1806, and 1809. Action: Change "The MSG_NOSIGNAL() macro" to "The MSG_NOSIGNAL flag" and remove italics. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 gwc:xxxxxxxxxxxxx Bug in XSHd3 2.2.2 (rdvk# 17) [gwc 2.2.2 nested headers] Mon, 9 Jul 2007 17:01:10 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 450 Line: 15684 Section: 2.2.2 Problem: The namespace tables in section 2.2.2 have some inconsistencies regarding header nesting. Firstly some prefixes have moved from one table to the other for their "primary" header, but still appear in the old place in the entry for another header that is allowed to make symbols visible from the primary header. Secondly, only a few headers have entries corresponding to the prefixes (or suffixes or complete names) for other headers from which they can make symbols visible. In most cases there is no explicit entry in the table - matching symbols are allowed by virtue of the statement on the header's main page in XBD that it may make symbols from the other header visible. It would be best to remove the few such prefixes etc. that do appear explicitly. Action: In the first table (pages 450 and 451): Delete the "in_" prefix from the entry. Delete the entry. Delete the "si_" prefix from the entry. In the second table (page 452): Delete the "S_" and "SEEK_" prefixes from the entry. Delete the entry. _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 gwc:xxxxxxxxxxxxx Bug in XSHd3 2.2.2 (rdvk# 26) [gwc 2.2.2 shading] Mon, 9 Jul 2007 17:02:50 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 450 Line: 15703 Section: 2.2.2 Problem: There are some shading problems in the table on pages 450 and 451. The first is editorial; the second is for consistency with interfaces that have moved from XSI to Base. Action: Unshade the and entries. Unshade the , and entries. _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 gwc:xxxxxxxxxxxxx Bug in XSHd3 2.3 (rdvk# 12) [gwc new error numbers] Fri, 20 Jul 2007 16:27:04 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 461 Line: 16136 Section: 2.3 Problem: Two additions are needed to section 2.3 Error Numbers for consistency with the addition of ENOTRECOVERABLE and EOWNERDEAD to errno.h and the pthread_mutex_lock() page. Action: After line 16136 add: "[ENOTRECOVERABLE] State not recoverable. The state protected by a robust mutex is not recoverable." After line 16156 add: "[EOWNERDEAD] Previous owner died. The owner of a robust mutex terminated while holding the mutex lock." _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 gwc:xxxxxxxxxxxxx Bug in XSHd3 2.4.3 (rdvk# 10) [gwc siginfo members] Wed, 11 Jul 2007 15:58:18 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the table from: int si_signo Signal number. int si_code Cause of the signal. union sigval si_value Signal value. to: int si_signo Signal number. int si_code Cause of the signal. pid_t si_pid Sending process ID. uid_t si_uid Real user ID of sending process. void * si_addr Address of faulting instruction. int si_status Exit value or signal. union sigval si_value Signal value. At line 16393 change: "The following values are defined for si_code" to "The following non-signal-specific values are defined for si_code" At line 16402 change: "If the signal was not generated by one of the functions or events listed above, the si_code shall be set to an implementation-defined value that is not equal to any of the values defined above." to: "Signal-specific values for si_code are also defined, as described in [xref to page]. If the signal was not generated by one of the functions or events listed above, si_code shall be set either to one of the signal-specific values described in [xref to page] or to an implementation-defined value that is not equal to any of the values defined above. If si_code is SI_USER or SI_QUEUE, [XSI]or any value less than or equal to 0[/XSI], then the signal was generated by a process and si_pid and si_uid shall be set to the process ID and the real user ID of the sender, respectively. In addition, si_addr, si_pid, si_status and si_uid shall be set for certain signal-specific values of si_code, as described in [xref to page]." On page 1871 line 59779 section sigaction, change: "The si_code member contains a code identifying the cause of the signal. If the value of si_code is less than or equal to 0, then the signal was generated by a process and si_pid and si_uid, respectively, indicate the process ID and the real user ID of the sender. The header description contains information about the signal-specific contents of the elements of the siginfo_t type." to: "The si_code member contains a code identifying the cause of the signal, as described in [xref to section 2.4.3]." Cross-volume changes to XBD: page 318 line 11036 section signal.h, change APPLICATION USAGE from: "None." to: "On systems not supporting the XSI option, the si_pid and si_uid members of siginfo_t are only required to be valid when si_code is SI_USER or SI_QUEUE. On XSI-conforming systems, they are also valid for all si_code values less than or equal to 0; however, it is unspecified whether SI_USER and SI_QUEUE have values less than or equal to zero and therefore XSI applications should check whether si_code has the value SI_USER or SI_QUEUE or is less than or equal to 0 to tell whether si_pid and si_uid are valid." _____________________________________________________________________________ Page: 467 Line: 16388 Section: 2.4.3 Problem: Section 2.4.3 Signal Actions needs to be updated for consistency with the changes made to the and sigaction pages to move some members of siginfo_t, and the meaning of si_code <= 0, from XSI to Base. While merging in the new description of si_code, I noticed a problem in that SI_USER and SI_QUEUE are cases where the signal is sent by a process. This overlaps with the (formerly XSI) requirement that si_code is <= 0 when the signal is from a process. Current XSI systems handle this by defining SI_USER and SI_QUEUE with values <= 0. If we extend this requirement to non-XSI systems it will break the ABI of any implementations where SI_USER and/or SI_QUEUE are positive. However, if we allow SI_USER and SI_QUEUE to be positive it will break any XSI applications that just check whether si_code is <= 0. The only solution I can see is to have an explicit XSI requirement that SI_USER and SI_QUEUE are <= 0. Non-XSI POSIX applications would check whether the signal is from a process by seeing if si_code is either SI_USER or SI_QUEUE or a value <= 0. Action: Change the table from: int si_signo Signal number. int si_code Cause of the signal. union sigval si_value Signal value. to: int si_signo Signal number. int si_code Cause of the signal. pid_t si_pid Sending process ID. uid_t si_uid Real user ID of sending process. void * si_addr Address of faulting instruction. int si_status Exit value or signal. union sigval si_value Signal value. At line 16393 change: "The following values are defined for si_code" to "The following non-signal-specific values are defined for si_code" At line 16402 change: "If the signal was not generated by one of the functions or events listed above, the si_code shall be set to an implementation-defined value that is not equal to any of the values defined above." to: "Signal-specific values for si_code are also defined, as described in [xref to page]. If the signal was not generated by one of the functions or events listed above, and not for one of the signal-specific reasons described in [xref to page], si_code shall be set to an implementation-defined value that is: a. not equal to any of the values defined for si_code in POSIX.1-200x; b. less than or equal to 0 if the signal was generated by a process. If si_code is SI_USER, SI_QUEUE, or any value less than or equal to 0, si_pid and si_uid shall be set to the process ID and the real user ID of the sender, respectively. In addition, si_addr, si_pid, si_status and si_uid shall be set for certain signal-specific values of si_code, as described in [xref to page]." On page 1871 line 59779 section sigaction, change: "The si_code member contains a code identifying the cause of the signal. If the value of si_code is less than or equal to 0, then the signal was generated by a process and si_pid and si_uid, respectively, indicate the process ID and the real user ID of the sender. The header description contains information about the signal-specific contents of the elements of the siginfo_t type." to: "The si_code member contains a code identifying the cause of the signal, as described in [xref to section 2.4.3]." Cross-volume changes to XBD: page 316 line 10989 section signal.h, add a new paragraph (shaded XSI): "The values of SI_USER and SI_QUEUE shall be less than or equal to zero." page 318 line 11036 section signal.h, change APPLICATION USAGE from: "None." to: "On XSI-conforming systems, all si_code values that indicate the signal was generated by a process are less than or equal to 0, and this includes SI_USER and SI_QUEUE. On systems not supporting the XSI option, SI_USER and SI_QUEUE may have positive values and therefore applications should check whether si_code has the value SI_USER or SI_QUEUE or is less than or equal to 0 to tell whether the signal was generated by a process on such systems." _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 gwc:xxxxxxxxxxxxx Defect in XSHd3 2.10.7 (rdvk# 11) [gwc socket nb bind] Tue, 10 Jul 2007 12:07:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: insert para before "The connect() function...", before "Data Transfers" Add new text as below as a new para. Editors may turn this into a list, reordering bind, connect, data transfers.. _____________________________________________________________________________ Page: 498 Line: 17677 Section: 2.10.7 Problem: Section 2.10.7 Socket I/O Mode needs to be updated for consistency with the new asynchronous feature of bind(). Action: Append to line 17677: "The bind() function initiates an address assignment and shall return without blocking when O_NONBLOCK is set; if the socket address cannot be assigned immediately, bind() shall return the error [EINPROGRESS] to indicate that the assignment was initiated successfully, but that it has not yet completed." _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 mh-austin:xxxxxx Bug in XSHd3 2.10.14 (rdvk# 36) [mh2007d3002] Tue, 10 Jul 2007 08:07:49 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: page 497 line 17640 section 2.10.6 Change from: A SIGPIPE signal is raised if a thread sends on a broken stream (one that is no longer connected). To: A SIGPIPE signal is raised if a thread attempts to send data on a broken stream (one that is no longer connected), except that the signal is suppressed if the MSG_NOSIGNAL flag is used in calls to send(), sendto(), and sendmsg(). page 499 line 17744 section 2.10.14 Change from: The SIGPIPE signal shall be sent to a thread that attempts to send data on a socket that is no longer able to send. In addition, the send operation fails with the error [EPIPE]. To: The SIGPIPE signal shall be sent to a thread that attempts to send data on a socket that is no longer able to send (one that is no longer connected), except that the signal is suppressed if the MSG_NOSIGNAL flag is used in calls to send(), sendto(), and sendmsg(). Regardless of whether the generation of the signal is suppressed, the send operation shall fail with the error [EPIPE]. After applying XSHbug2.txt ERN 195 (against 2004 edition) page 502 line 17846 section 2.10.16/SO_KEEPALIVE Delete: and threads writing to that socket shall be/are notified with a SIGPIPE signal page 1803 line 57786 section send page 1805 line 57881 section sendmsg page 1808 line 57999 section sendto Change from: and if the socket is of type SOCK_STREAM, To: if the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the MSG_NOSIGNAL flag is not set, Cross-volume change to XRAT: page 3405 line 115930 section B.2.3 Change from: This condition normally generates the signal SIGPIPE; the error is returned if the signal does not terminate the process. To: This condition normally generates the signal SIGPIPE; the error is returned if the generation of the signal is suppressed or the signal does not terminate the process. _____________________________________________________________________________ Page: 499 Line: 17744 Section: 2.10.14 Problem: Various places in the text require the SIGPIPE signal to be generated without mentioning any exception for MSG_NOSIGNAL. Because the new MSG_NOSIGNAL flag "requests" not to send the signal (page 1802 line 57751) but the signal still "shall be sent" (page 499 line 17744 and others), a literal interpretation requires that the signal be sent regardless of this flag. Text that requires SIGPIPE generation should not require it in situations where the MSG_NOSIGNAL flag was used. SIGPIPE generation is mentioned in a number of places, including in the description of the SO_KEEPALIVE option on both the getsockopt() and setsockopt() pages. 2004 ERN 195 moves this text to section 2.10.16. The proposed action below removes the mention of SIGPIPE within the description of SO_KEEPALIVE since SIGPIPE is not triggered by SO_KEEPALIVE, but rather by a separate explicit send operation, if the connection is broken. However other sections already require this behavior for such send operations, independent of the SO_KEEPALIVE option. Besides being redundant and now incomplete, it is misleading to mention SIGPIPE here, since an application that performs regular sends has no need for SO_KEEPALIVE. SO_KEEPALIVE is used to prevent the connection from staying open indefinitely if the remote host crashes, and the local application would not normally send data except in response to data received. In this case enabling SO_KEEPALIVE allows the remote crash to eventually be detected by a return from read/recv/poll/select. Action: page 497 line 17640 section 2.10.6 Change from: A SIGPIPE signal is raised if a thread sends on a broken stream (one that is no longer connected). To: A SIGPIPE signal is raised if a thread attempts to send data on a broken stream (one that is no longer connected) without using the MSG_NOSIGNAL flag. page 499 line 17744 section 2.10.14 Change from: The SIGPIPE signal shall be sent to a thread that attempts to send data on a socket that is no longer able to send. In addition, the send operation fails with the error [EPIPE]. To: The SIGPIPE signal shall be sent to a thread that attempts to send data on a socket that is no longer able to send, if the generation of the signal is not suppressed by sending with the MSG_NOSIGNAL flag. Regardless of whether the generation of the signal is suppressed, the send operation fails with the error [EPIPE]. (if 2004 ERN 195 applied:) page 502 line 17846 section 2.10.16/SO_KEEPALIVE (if 2004 ERN 195 not applied:) page 1040 line 35187 section getsockopt/SO_KEEPALIVE page 1843 line 58895 section setsockopt/SO_KEEPALIVE Delete: and threads writing to that socket shall be/are notified with a SIGPIPE signal page 1803 line 57786 section send page 1805 line 57881 section sendmsg page 1808 line 57999 section sendto Change from: and if the socket is of type SOCK_STREAM, To: if the socket is of type SOCK_STREAM and the MSG_NOSIGNAL flag is not set, Cross-volume change to XRAT: page 3405 line 115930 section B.2.3 Change from: This condition normally generates the signal SIGPIPE; the error is returned if the signal does not terminate the process. To: This condition normally generates the signal SIGPIPE; the error is returned if the generation of the signal is suppressed or the signal does not terminate the process. _____________________________________________________________________________ COMMENT Enhancement Request Number 10 gwc:xxxxxxxxxxxxx Bug in XSHd3 _Exit (rdvk# 20) [gwc conseq of termin] Wed, 11 Jul 2007 15:20:50 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change last sentence of 3rd para DESC from: Finally, the calling process is terminated with the consequences described below. To: Finally, the calling process shall be terminated with the consequences described below. Change from These functions shall terminate the calling process with the following consequences: line 18589 [CX ] Process termination caused by any reason shall have the following consequences. _____________________________________________________________________________ Page: 524 Line: 18656 Section: _Exit Problem: The _Exit() page has a list headed "Consequences of Process Termination" which lists rules that apply not only to termination by calling _Exit() and _exit() (the functions described on that page) but to all forms of process termination. Currently this only becomes apparent by noticing that there are references to the list from other parts of the standard that talk about process termination, or "as if" statements referring to _exit() or exit(). We made improvements in this area in the last draft (clarifying which part of the _Exit() page contained the "consequences of termination" referred to elsewhere). However, the _Exit() page itself still does not make clear that the list applies to all forms of termination. In POSIX.1-1990 the list of consequences was in the description of _exit() in section 3.2.2.2 and had a statement after it saying: "These consequences shall occur on process termination for any reason." This statement should be reinstated to make it clear that the list does not only apply to _Exit() and _exit(). Action: Add a new paragraph after the bullet list: "These consequences shall occur on process termination for any reason." _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 ebb9:xxxxxxx Bug in XSHd3 alphasort (rdvk# 39) {ebb.alphasort.1} Wed, 25 Jul 2007 23:34:45 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change from The alphasort( ) function can be used as the comparison function for the scandir( ) function to sort the directory entries into alphabetical order. Sorting happens as if by calling the strcoll( ) function on the d_name element of the dirent structures passed as the two parameters. Its parameters are the two directory entries, d1 and d2, to compare. to: The alphasort( ) function can be used as the comparison function for the scandir( ) function to sort the directory entries, d1 and d2, into alphabetical order. Sorting happens as if by calling the strcoll( ) function on the d_name element of the dirent structures passed as the two parameters. If the strcoll() function fails the return value of alphasort() is unspecified. The alphasort( ) function shall not change the setting of errno if successful. Since no return value is reserved to indicate an error, an application wishing to check for error situations should set errno to 0, then call alphasort(), then check errno. Change para ~ 19898 from The scandir( ) function shall scan the directory dir, calling the function referenced by sel on each directory entry. Entries for which the function referenced by sel returns non-zero shall be stored in strings allocated as if by a call to malloc( ), and sorted using qsort( ) with the comparison function compar, and collected in array namelist which shall be allocated as if by a call to malloc( ). If sel is a null pointer, all entries shall be selected. to The scandir( ) function shall scan the directory dir, calling the function referenced by sel on each directory entry. Entries for which the function referenced by sel returns non-zero shall be stored in strings allocated as if by a call to malloc( ), and sorted as if by a call to qsort() with the comparison function compar, except that compar need not provide total ordering. The strings are collected in array namelist which shall be allocated as if by a call to malloc( ). If sel is a null pointer, all entries shall be selected. If the comparison function /compar/ does not provide total ordering the order in which the directory entries are stored is unspecified. Add to APPLICATION USAGE If dir contains filenames that contain characters outside the domain of the collating sequence of the current locale, alphasort() need not provide a total ordering. _____________________________________________________________________________ Page: 565 Line: 19891 Section: alphasort Problem: The strcoll() function is allowed to fail, in which case the return value is indeterminite. But qsort() requires a total ordering from its comparison function, which would be violated by indeterminism. Therefore, alphasort needs to be specified how to behave in the face of file names that are invalid encodings in the current locale. As alphasort was not modified in draft 3, this aardvark should be considered in light of making the standard internally consistent. This aardvark tries to be as permissive as possible, introducing only the requirement that encoding errors are handled in a total ordering, without stating what order encoding errors are sorted into. Although this aardvark does not do so, it would also be possible to add a constraint on qsort, that errno is left unchanged unless the comparison function sets it; on scandir, that on success errno is left unchanged unless the comparison or selection function sets it; and on alphasort, that errno is left unchanged unless strcoll detects a failure. That way, an application could detect an encoding error that was handled by alphasort by setting errno to 0, then checking if errno is still 0 after a successful scandir. Action: Update the sentence on line 19891: Sorting happens as if by calling the strcoll( ) function on the d_name element of the dirent structures passed as the two parameters. with an additional clause: Sorting happens as if by calling the strcoll( ) function on the d_name element of the dirent structures passed as the two parameters, with the additional stipulation that any comparison failures are handled in a total ordering. _____________________________________________________________________________ OBJECTION Enhancement Request Number 12 ebb9:xxxxxxx Bug in XSHd3 scandir (rdvk# 41) {ebb.alphasort.2} Thu, 26 Jul 2007 16:03:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At line 19949, replace the Application Usage of "None." with: The scandir( ) function may allocate dynamic storage during its operation. If scandir( ) is forcibly terminated, such as by longjmp( ) or siglongjmp( ) being executed by the function pointed to by sel or compar, or by an interrupt routine, scandir( ) does not have a chance to free that storage, so it remains permanently allocated. A safe way to handle interrupts is to store the fact that an interrupt has occurred, then wait until scandir( ) returns to act on the interrupt. nftw p1336 At line 44264, replace the Application Usage of "None." with: The nftw( ) function may allocate dynamic storage during its operation. If nftw( ) is forcibly terminated, such as by longjmp( ) or siglongjmp( ) being executed by the function pointed to by fn or an interrupt routine, nftw( ) does not have a chance to free that storage, so it remains permanently allocated. A safe way to handle interrupts is to store the fact that an interrupt has occurred, and arrange to have the function pointed to by fn return a non-zero value at its next invocation. _____________________________________________________________________________ Page: 566 Line: 19949 Section: scandir Problem: The standard already has a nice application warning that the use of abrupt exits inside a callback of ftw can result in a memory leak. scandir is subject to the same problem, but bears no such warning (likewise for nftw). Since scandir was not edited for draft 3, this change should be considered in light of making new material added by API Set 1 consistent with the rest of the specification. Action: At line 19949, replace the Application Usage of "None." with: The scandir( ) function allocates dynamic storage during its operation. If scandir( ) is forcibly terminated, such as by longjmp( ) or siglongjmp( ) being executed by the function pointed to by sel or compar, or by an interrupt routine, scandir( ) does not have a chance to free that storage, so it remains permanently allocated. A safe way to handle interrupts is to store the fact that an interrupt has occurred, then wait until scandir( ) returns to act on the interrupt. At line 44264, replace the Application Usage of "None." with: The nftw( ) function may allocate dynamic storage during its operation. If nftw( ) is forcibly terminated, such as by longjmp( ) or siglongjmp( ) being executed by the function pointed to by fn or an interrupt routine, nftw( ) does not have a chance to free that storage, so it remains permanently allocated. A safe way to handle interrupts is to store the fact that an interrupt has occurred, and arrange to have the function pointed to by fn return a non-zero value at its next invocation. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 13 gwc:xxxxxxxxxxxxx Bug in XSHd3 bind (rdvk# 21) [gwc bind new errors] Mon, 9 Jul 2007 17:04:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 593 Line: 20737 Section: bind Problem: The new EALREADY and EINPROGRESS errors have been added under "may fail". They were supposed to be "shall fail" (as in the description). Action: Move the EALREADY and EINPROGRESS errors from the "may fail" group (line 20734) to the "shall fail" group (line 20705). _____________________________________________________________________________ COMMENT Enhancement Request Number 14 Michael T Kerrisk BUG in XSHd3 bind (rdvk# 43) Tue, 24 Jul 2007 10:46:46 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 593 Line: 20749 Section: bind Problem: This is an example program for this interface. As discussed with Andrew off list, the example programs I'm submitting come from already published versions in the Linux man pages, and each was written solely by me. I assign a non-exclusive copyright to The Open Group. This is an example program, intended to clarify the use of this interface for the reader of the standard. Page and line numbers refer to draft 3 of the revision. Action: substitute line 20749 ("None") with the following text: The following code segment shows how to create a socket and bind it to a name in the AF_UNIX domain. #define MY_SOCK_PATH "/somepath" int sfd; struct sockaddr_un my_addr; sfd = socket(AF_UNIX, SOCK_STREAM, 0); if (sfd == -1) /* Handle error */; memset(&my_addr, `\0`, sizeof(struct sockaddr_un)); /* Clear structure */ my_addr.sun_family = AF_UNIX; strncpy(my_addr.sun_path, MY_SOCK_PATH, sizeof(my_addr.sun_path) - 1); if (bind(sfd, (struct sockaddr *) &my_addr, sizeof(struct sockaddr_un)) == -1) /* Handle error */; _____________________________________________________________________________ OBJECTION Enhancement Request Number 15 gwc:xxxxxxxxxxxxx Bug in XSHd3 bsearch (rdvk# 24) [gwc bsearch scanf] Mon, 16 Jul 2007 09:18:31 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 596 Line: 20823 Section: bsearch Problem: The bsearch() example has been changed to use the scanf() memory allocation modifier for %s, but it uses the old proposed 'M' instead of the 'm' that was actually added for scanf(). Action: Change "%Ms" to "%ms". _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 gwc:xxxxxxxxxxxxx Bug in XSHd3 dirfd (rdvk# 34) [gwc dirfd v fdopendir] Mon, 9 Jul 2007 17:11:45 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The behavior of future calls to readdir() and readdir_r() is undefined if the application attempts to alter the file position indicator using the returned file descriptor. The behavior of future calls to closedir(), readdir(), and readdir_r() is undefined if the application attempts to close the file descriptor." to "If any attempt is made to close the file descriptor, or to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), or rewinddir(), the behavior is undefined." On page 795 line 27015-27016 section fdopendir, insert a comma before "other than by", and change "implementation-defined" to "undefined". _____________________________________________________________________________ Page: 697 Line: 23915 Section: dirfd Problem: The call sequences fd = open(... d = fdopendir(fd); and d = opendir(.... fd = dirfd(d); effectively set up the same situation, where fd is a file descriptor associated with an open directory stream. However, the descriptions of dirfd() and fdopendir() are inconsistent as regards what can (or can't) be done with this file descriptor. dirfd() says: "The behavior of future calls to readdir() and readdir_r() is undefined if the application attempts to alter the file position indicator using the returned file descriptor. The behavior of future calls to closedir(), readdir(), and readdir_r() is undefined if the application attempts to close the file descriptor." fdopendir() says: "if any attempt is made to close the file descriptor, or to modify the state of the associated description other than by means of closedir(), readdir(), readdir_r(), or rewinddir(), the behavior is implementation-defined." The statement on the fdopendir() page seems the more correct to me. It allows for the possibility that changes to the state of the open file description other than just to its file position indicator could affect the behaviour of the directory stream. I also don't see why the dirfd() statement needs to say the behaviour is undefined if the fd is closed. If directory streams are implemented using a file descriptor then readdir() and closedir() should return an EBADF error. If directory streams are not implemented using a file descriptor then the fd is independently open for the same directory, and closing it should not affect readdir() (but closedir() could presumably either succeed or give an EBADF error). Therefore I suggest adopting the fdopendir() statement on both pages, but with two minor changes: 1. It seems an unnecessary burden on implementors to make them document all the ways in which a state change affects the behaviour of directory streams, so I think it should say "unspecified" rather than "implementation-defined". 2. An extra comma is needed, since calling closedir() is allowed, but closedir() counts as an "attempt to close the file descriptor". Action: Change "The behavior of future calls to readdir() and readdir_r() is undefined if the application attempts to alter the file position indicator using the returned file descriptor. The behavior of future calls to closedir(), readdir(), and readdir_r() is undefined if the application attempts to close the file descriptor." to "If any attempt is made to close the file descriptor, or to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), or rewinddir(), the behavior is unspecified." On page 795 line 27015-27016 section fdopendir, insert a comma before "other than by", and change "implementation-defined" to "unspecified". _____________________________________________________________________________ COMMENT Enhancement Request Number 17 gwc:xxxxxxxxxxxxx Bug in XSHd3 fdopendir (rdvk# 6) [gwc fdopendir ex2] Mon, 16 Jul 2007 09:24:17 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 796 Line: 27067 Section: fdopendir Problem: The second fdopendir() example has a couple of minor problems. 1. The introductory comment doesn't quite match the code. 2. It uses %d to print an off_t value. Action: Change "The following program fragment searches through a given directory looking for files larger than 1 MB." to "The following program searches through a given directory looking for files whose name does not begin with a dot and whose size is larger than 1 MiB." Insert before line 27073: #include On line 27097 change: printf("%s: %dk\n", dp->d_name, statbuf.st_size / 1024); to: printf("%s: %jdK\n", dp->d_name, (intmax_t)(statbuf.st_size / 1024)); _____________________________________________________________________________ OBJECTION Enhancement Request Number 18 ebb9:xxxxxxx Bug in XSHd3 fdopendir (rdvk# 1) {ebb.fdopendir} Wed, 20 Jun 2007 19:30:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove line 27102 close(dfd); Add a comment to 27101 closedir(d); // note this implicitly closes dfd _____________________________________________________________________________ Page: 797 Line: 27082 Section: fdopendir Problem: Line 27013 of fdopendir forbids certain use of a file descriptor after handing it to fdopendir. The example starting at line 27069 currently violates this by using dfd in openat and close after the fact. Action: Replace line 27082: if ((d = fdopendir((dfd = open("./tmp", O_RDONLY)))) == NULL) { with the following two lines: dfd = open("./tmp", O_RDONLY); if ((d = fdopendir(dup(dfd))) == NULL) { _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 gwc:xxxxxxxxxxxxx Bug in XSHd3 fgetwc (rdvk# 13) [gwc wide and narrow mix] Mon, 16 Jul 2007 12:09:52 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 826 Line: 27888 Section: fgetwc Problem: The fgetwc() page says: "The last data access timestamp shall be marked for update by the first successful execution of fgetc(), fgets(), fgetwc(), fgetws(), fread(), fscanf(), getc(), getchar(), gets(), or scanf() using stream that returns data not supplied by a prior call to ungetc() or ungetwc()." This list of functions contains byte input functions as well as wide-character input functions. However, section 2.5.2 states "Byte input/output functions cannot be applied to a wide-oriented stream, and wide-character input/output functions cannot be applied to a byte-oriented stream." The byte input functions should be removed from the list. Likewise ungetc() cannot be used on a wide-oriented stream and should not be mentioned. The descriptions of the other wide-character input functions have the same problem. The fread() page has the opposite problem: it is a byte input function, but the function list includes some wide-character input functions and it mentions ungetwc(). The affected paragraphs all have change bars, but the change was in text that comes before the function lists, so just in case this does not meet the narrowing-down rules I should point out that the implication that byte and wide-character input functions can be mixed is in conflict with the C Standard and the change should therefore be in scope anyway. Action: Change "fgetc(), fgets(), fgetwc(), fgetws(), fread(), fscanf(), getc(), getchar(), gets(), or scanf()" to "fgetwc(), fgetws(), fwscanf(), getwc(), getwchar(), vfwscanf(), vwscanf(), or wscanf()" On line 27889 delete "ungetc() or". Repeat the same two changes for: page 828 line 27965 section fgetws page 953 line 32527 section fwscanf (There may be slight variation in the current function lists, but they are not relevant: in each case the listed functions should be replaced with the same one specified above for the fgetwc() page.) On page 885 line 30035 section fread, delete "fgetwc(), fgetws()," On page 885 line 30036 section fread, delete "or ungetwc()" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 20 nick:xxxxxxxxxx Bug in XSHd3 fmemopen (rdvk# 53) {nms-fmemopen-typos} Mon, 13 Aug 2007 21:40:18 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 838 Line: 28309 Section: fmemopen Problem: In two places the current text talks about "advancing the current buffer position behind the current buffer size" (lines 28309 and 28317). I do not understand this terminology, and suspect that this is a simple typo where "behind" should be "beyond". Action: Replace the word "behind" on lines 28309 and 28317 with the word "beyond". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 21 ebb9:xxxxxxx Bug in XSHd3 fmemopen (rdvk# 19) {ebb.fmemopen} Thu, 19 Jul 2007 15:05:25 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 839 Line: 28338 Section: fmemopen Problem: The example for fmemopen uses strlen without a prior declaration. As this section was not edited for draft 3, this change should be considered under the rule of making the draft internally consistent (code examples should use valid code). Action: At line 28338, add a line: #include _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 gwc:xxxxxxxxxxxxx Bug in XSHd3 fprintf (rdvk# 25) [gwc dprintf timestamps] Fri, 6 Jul 2007 16:58:36 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 869 Line: 29497 Section: fprintf Problem: The fprintf page is missing a statement about timestamp update by dprintf(). Action: Change "The last data modification and last file status change timestamps of the file shall be marked for update between the call to a successful execution of fprintf() or printf() and the next successful completion of a call to fflush() or fclose() on the same stream or a call to exit() or abort()." to "The last data modification and last file status change timestamps of the file shall be marked for update: a. between the call to a successful execution of fprintf() or printf() and the next successful completion of a call to fflush() or fclose() on the same stream or a call to exit() or abort(); b. upon successful completion of a call to dprintf()." _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 ebb9:xxxxxxx Bug in XSHd3 free (rdvk# 52) {ebb.free} Mon, 23 Jul 2007 21:49:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: On page 566 line 19949 (alphasort/scandir), change "None" to For functions that allocate memory as if by malloc(), the application should release such memory when it is no longer required by a call to free(). For scandir(), this is /namelist/ (including all of the individual strings in /namelist/). Page 566 line 19955, remove "malloc()" Page 887 line 30089-30091, change: Otherwise, if the argument does not match a pointer earlier returned by the calloc(), malloc(), posix_memalign(), realloc(), or strdup() function, or if the space has been deallocated by a call to free() or realloc(), the behavior is undefined. to Otherwise, if the argument does not match a pointer earlier returned by a function in POSIX.1-200x that allocates memory as if by malloc(), or if the space has been deallocated by a call to free() or realloc(), the behavior is undefined. Page 887 line 30107 (not sure if we did this already) Change entire line to: calloc(), malloc(), posix_memalign, realloc() Page 905, line 30764 (fscanf): add new paragraph For functions that allocate memory as if by malloc(), the application should release such memory when it is no longer required by a call to free(). For fscanf(), this is memory allocated via use of the 'm' assignment-allocation character. Page 934 line 31728 (ftw) Remove malloc() from the list. Page 954 line 32560 (fwscanf): add new paragraph For functions that allocate memory as if by malloc(), the application should release such memory when it is no longer required by a call to free(). For fwscanf(), this is memory allocated via use of the 'm' assignment-allocation character. Page 964 line 32833, delete the sentence "Also, malloc() and free() are used nowhere else in this volume of POSIX.1-200x." Page 1950 line 62039 (strdup/strndup) Replace "None" with: For functions that allocate memory as if by malloc(), the application should release such memory when it is no longer required by a call to free(). For strdup() and strndup(), this is the return value. Page 1950 line 62047 remove malloc(). Page 2155 line 68032 (wcsdup) Replace "None" with: For functions that allocate memory as if by malloc(), the application should release such memory when it is no longer required by a call to free(). For wcsdup() this is the return value. line 68020 (wcsdup) change from The wcsdup( ) function shall return a pointer to a new wide-character string, which is the duplicate of the wide-character string string. to: The wcsdup( ) function shall return a pointer to a new wide-character string, allocated as if by a call to malloc(), which is the duplicate of the wide-character string string. -- realpath p 1715 l 54996 change from If resolved_name is a null pointer, the generated pathname shall be stored as a null-terminated string in a buffer allocated by realpath( ). to If resolved_name is a null pointer, the generated pathname shall be stored as a null-terminated string in a buffer allocated as if by a call to malloc(). Add to APP USAGE For functions that allocate memory as if by malloc(), the application should release such memory when it is no longer required by a call to free(). For realpath() this is the return value. ==================================================== While doing the above, I noticed several examples have program fragments that malloc() but then end "..." I believe in general it is good advice to remind readers that the application has a responsibility to free such memory, so here are the edits I believe will improve these examples: Page 963 line 32823 (getcwd) NB! This change is not really associated with the other changes in this list...it is simply improving an example that uses malloc()! Add new lines after ellipsis: free (buf); Page 980 line 33361 (getgrgid) NB! This change is not really associated with the other changes in this list...it is simply improving an example that uses malloc()! Add new line after ellipsis free (buffer); Page 983 line 33488 (getgrnam) NB! This change is not really associated with the other changes in this list...it is simply improving an example that uses malloc()! Add new line after ellipsis free (buffer); Page 1022 line 34653 (getpwnam) NB! This change is not really associated with the other changes in this list...it is simply improving an example that uses malloc()! Add new line after ellipsis free (buffer); Page 1026 line 34781 (getpwuid) NB! This change is not really associated with the other changes in this list...it is simply improving an example that uses malloc()! Add new line after ellipsis free (buffer); Page 1022 line 34653 (getpwnam) NB! This change is not really associated with the other changes in this list...it is simply improving an example that uses malloc()! Add new line after ellipsis free (buffer); _____________________________________________________________________________ Page: 887 Line: 30090 Section: free Problem: The list of functions that generate valid pointers for free() is incomplete, in light of the API set additions. Since free was not changed in draft 3, this change should be considered in light of consistency with other additions. Furthermore, strdup() was moved from XSI to Base, but does not exist in the C standard, so now that it is no longer XSI shaded, it should be CX shaded. This aardvark does not address the asymmetry in the fact that there is now strndup but no wcsndup, but if that is addressed independently, free() would also need to list wcsndup. Action: At line 30090, replace this list: calloc(), malloc(), posix_memalign(), realloc(), strdup() with this: calloc(), getdelim(), getline(), malloc(), open_memstream, open_wmemstream, posix_memalign(), realloc(), strdup(), strndup(), wscdup() _____________________________________________________________________________ COMMENT Enhancement Request Number 24 Michael T Kerrisk BUG in XSHd3 getaddrinfo (rdvk# 51) Tue, 24 Jul 2007 10:42:54 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: #include #include #include #include #include #include int main(int argc, char *argv[]) { struct addrinfo *result, *rp; int sfd, s; if (argc != 2) { fprintf(stderr, "Usage: %s port\n", argv[0]); exit(EXIT_FAILURE); } struct addrinfo hints = {}; hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; hints.ai_flags = AI_PASSIVE; hints.ai_protocol = 0; s = getaddrinfo(NULL, argv[1], &hints, &result); if (s != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s)); exit(EXIT_FAILURE); } /* getaddrinfo() returns a list of address structures. Try each address until a successful bind(). If socket(2) (or bind(2)) fails, close the socket and try the next address. */ for (rp = result; rp != NULL; rp = rp->ai_next) { sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol); if (sfd == -1) continue; if (bind(sfd, rp->ai_addr, rp->ai_addrlen) == 0) break; /* Success */ close(sfd); } if (rp == NULL) { /* No address succeeded */ fprintf(stderr, "Could not bind\n"); exit(EXIT_FAILURE); } freeaddrinfo(result); /* No longer needed */ /* ... use socket bound to sfd ... */ } _____________________________________________________________________________ Page: 891 Line: 30262 Section: getaddrinfo Problem: This is an example program for this interface. As discussed with Andrew off list, the example programs I'm submitting come from already published versions in the Linux man pages, and each was written solely by me. I assign a non-exclusive copyright to The Open Group. This is an example program, intended to clarify the use of this interface for the reader of the standard. Page and line numbers refer to draft 3 of the revision. Action: substitute line 30262 ("None") with the following text: The following (incomplete) program demonstrates the use of getaddrinfo() to obtain the socket address structure(s) for the service named in the program's command-line argument. The program then loops through each of the address structures attempting to create and bind a socket to the address, until it performs a successful bind(). #include #include #include #include #include #include int main(int argc, char *argv[]) { struct addrinfo hints; struct addrinfo *result, *rp; int sfd, s; if (argc != 2) { fprintf(stderr, "Usage: %s port\n", argv[0]); exit(EXIT_FAILURE); } memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; hints.ai_flags = AI_PASSIVE; hints.ai_protocol = 0; s = getaddrinfo(NULL, argv[1], &hints, &result); if (s != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s)); exit(EXIT_FAILURE); } /* getaddrinfo() returns a list of address structures. Try each address until a successful bind(). If socket(2) (or bind(2)) fails, close the socket and try the next address. */ for (rp = result; rp != NULL; rp = rp->ai_next) { sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol); if (sfd == -1) continue; if (bind(sfd, rp->ai_addr, rp->ai_addrlen) == 0) break; /* Success */ close(sfd); } if (rp == NULL) { /* No address succeeded */ fprintf(stderr, "Could not bind\n"); exit(EXIT_FAILURE); } freeaddrinfo(result); /* No longer needed */ /* ... */ } -- Michael Kerrisk mtk-lists:xxxxxxx Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 gwc:xxxxxxxxxxxxx Bug in XSHd3 fscanf (rdvk# 27) [gwc fscanf m mod] Tue, 10 Jul 2007 12:10:21 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 901 Line: 30572 Section: fscanf Problem: The statement "The %s, %S and %[ conversion specifiers shall accept an optional assignment-allocation character 'm'" omits the %c and %C conversion specifiers, which accept 'm'. Also, the %S (and %C if added) should really be XSI shaded, but that would be difficult since the whole para is CX. A solution would be just to list %c, %s and %[ here, since %C and %S are stated to be equivalent to %lc and %ls. The fwscanf page has the same problem, but also has a problem in the %c description. Part of it has not been updated in line with the other 'm' character updates. Action: Change "%s, %S and %[" to "%c, %s and %[". On page 950 line 32375 section fwscanf, change "%s, %S and %[" to "%c, %s and %[". On page 953 line 32483 section fwscanf, change "The corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence. No null character is added." to "No null character is added. If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to the initial element of a character array large enough to accept the sequence. [CX]Otherwise, the application shall ensure that the corresponding argument is a pointer to a pointer to a char.[/CX]" _____________________________________________________________________________ OBJECTION Enhancement Request Number 26 drepper:xxxxxxxxxx Bug in XSHd3 fscanf() (rdvk# 8) {ud-fscanf-1} Fri, 20 Jul 2007 17:24:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_25 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 901 Line: 30572 Section: fscanf() Problem: The list preceding the description of the assignment allocation character fails to miss 'c' and 'C' which are also affected by it. Action: Change beginning of line 30572 from The %s, %S, and %[ conversion specifiers to The %c, %C, %s, %S, and %[ conversion specifiers _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 drepper:xxxxxxxxxx Bug in XSHd3 fscanf() (rdvk# 49) {ud-scanf-m} Sat, 28 Jul 2007 22:56:45 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change in lines 30578ff: In that case, any memory successfully allocated for other parameters using assignment-allocation character 'm' by this call shall be freed. to If the function returns EOF, any memory successfully allocated for parameters using assignment-allocation character 'm' by this call shall be freed before the function returns. In RETURN VALUE section change from If a read CX error occurs, the error indicator for the stream is set, EOF shall be returned, and errno shall be set to indicate the error. To If any error occurs, EOF shall be returned, [CX]and errno shall be set to indicate the error. [/CX]If a read error occurs the error indicator for the stream shall be set. Change in lines 32382 fwscanf p 950: In that case, any memory successfully allocated for other parameters using assignment-allocation character 'm' by this call shall be freed. to If the function returns EOF, any memory successfully allocated for parameters using assignment-allocation character 'm' by this call shall be freed before the function returns. p954 l32533 fwscanf In RETURN VALUE section change from If a read CX error occurs, the error indicator for the stream is set, EOF shall be returned, and errno shall be set to indicate the error. To If any error occurs, EOF shall be returned, [CX]and errno shall be set to indicate the error. [/CX]If a read error occurs the error indicator for the stream shall be set. _____________________________________________________________________________ Page: 901 Line: 30578 Section: fscanf() Problem: The specification currently demands that all memory allocated in scanf due to 'm' modifiers is freed in case the call failed due to an internal ENOMEM error. This is not sufficient. If scanf returns EOF for any other reason the caller has no idea which if the pointers passed in for 'm' parameters points to valid memory and which not. One possibility would be to require that all pointers are set by the implementation to NULL before returning but this seems to be less optimal than the alternative: require all memory to be freed before returning EOF. Action: Change in lines 30578ff: In that case, any memory successfully allocated for other parameters using assignment-allocation character 'm' by this call shall be freed. to In case the function returns EOF, any memory successfully allocated for parameters using assignment-allocation character 'm' by this call shall be freed. _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 gwc:xxxxxxxxxxxxx Bug in XSHd3 fstatat (rdvk# 5) [gwc symlink inodes] Mon, 18 Jun 2007 16:11:37 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: On Page: 915 Line: 31096 Section: fstatat Change "For symbolic links, the st_mode member shall contain meaningful information when used with the file type macros, and the st_size member shall contain the length of the pathname contained in the symbolic link. File mode bits and the contents of the remaining members of the stat structure are unspecified. The value returned in the st_size member is the length of the contents of the symbolic link, and does not count any trailing null." to "For symbolic links, the st_mode member shall contain meaningful information when used with the file type macros. The file mode bits in st_mode are unspecified. The structure members st_ino, st_dev, st_uid, st_gid, st_atim, st_ctim, and st_mtim shall have meaningful values and the value of the st_nlink member shall be set to the number of (hard) links to the symbolic link. The value of the st_size member shall bet set to the length of the pathname contained in the symbolic link not including any terminating null byte." On page 2460 line 79290 section chown, replace the -h description with "For each file operand that names a file of type symbolic link, chown shall attempt to set the user ID of the symbolic link. If a group ID was specified, for each file operand that names a file of type symbolic link, chown shall attempt to set the group ID of the symbolic link." On page 2460 line 79308 section chown, delete "if the system supports this operation" On page 1170 line 39190 section lchown, delete "[EOPNOTSUPP] The path argument names a symbolic link and the implementation does not support setting the owner or group of a symbolic link." On page 1180 line 39471 section link, delete "unless the implementation does not support making hard links to symbolic links in which case the linkat() call shall fail" On page 1181 line 39505 section link, delete "[EOPNOTSUPP] The AT_SYMLINK_FOLLOW flag is clear in the flag argument, the path1 argument names a symbolic link, and the implementation does not support making hard links to symbolic links." On page 1704 line 54608 section readdir, append "The value of the structure's d_ino member shall be set to the file serial number of the file named by the d_name member. If the d_name member names a symbolic link, the value of the d_ino member shall be set to the file serial number of the symbolic link itself." On page 1704 line 54623 section readdir, delete "If the entry names a symbolic link, the value of the d_ino member is unspecified." On page 1706 line 54708 section readdir, insert a new paragraph: "When returning a directory entry for the root of a mounted file system, some historical implementations of readdir() returned the file serial number of the underlying mount point, rather than of the root of the mounted file system. This behavior is considered to be a bug, since the underlying file serial number has no significance to applications." On page 1709 line 54808 section readlink, delete "[EACCES] Read permission is denied for the symbolic link referred to by path." On page 2005 line 63682 section symlink, insert three new paragraphs: "The symbolic link's user ID shall be set to the process' effective user ID. The symbolic link's group ID shall be set to the group ID of the parent directory or to the effective group ID of the process. Implementations shall provide a way to initialize the symbolic link's group ID to the group ID of the parent directory. Implementations may, but need not, provide an implementation-defined way to initialize the symbolic link's group ID to the effective group ID of the calling process. The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-200x shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified. Upon successful completion, symlink() shall mark for update the last data access, last data modification, and last file status change timestamps of the symbolic link. Also, the last data modification and last file status change timestamps of the directory that contains the new entry shall be marked for update." Cross-volume changes to XCU: On page 2789 line 92056 section ls, append For a symbolic link, the time used as the sort key is that of the symbolic link itself, unless 'ls' is evaluating its file information to be that of the file referenced by the link (see the -H and -L options). On page 2926 line 97400 section pax, delete "except that if the files to be linked are symbolic links and the system is not capable of making hard links to symbolic links, then separate copies of the symbolic link shall be created instead". _____________________________________________________________________________ Page: 915 Line: 31096 Section: fstatat Problem: This aardvark completes an action on me from the 2007-06-07 teleconference, as a result of the discussion of XSH ERN 155, to produce detailed changes for draft 3 that remove the option of no-inode symlinks. The non-symlink-related changes from XSH ERN 155 are included here, so that this aardvark can supersede XSH ERN 155. This aardvark also supersedes XCU ERN 147 for ls -t. Mandating inodes for symlinks resolves many issues with the current standard, but one issue remains regarding symlink permissions. Currently readlink() is allowed to fail with EACCES if the symlink has no read permission, but there is no allowance for possible failure to read the contents of a symbolic link during pathname resolution, and there is no requirement on how symlink() sets the permissions on implementations where readlink() honours them. A solution to this is included below: remove the optional readlink() EACCES error and mandate that all interfaces ignore the permissions. The alternative would be to add optional EACCES errors to all functions that take a pathname, along the lines of "Read permission was denied for a symbolic link which needed to be followed to resolve the path argument"; add requirements for symlink() on how it sets the permissions on implementations where readlink() honours them; require that st_mode contains the actual permissions on implementations where readlink() honours them; add a way for applications to query whether readlink() honours symlink permissions; and (probably) add lchmod() and chmod -h. Action: Change "For symbolic links, the st_mode member shall contain meaningful information when used with the file type macros, and the st_size member shall contain the length of the pathname contained in the symbolic link. File mode bits and the contents of the remaining members of the stat structure are unspecified. The value returned in the st_size member is the length of the contents of the symbolic link, and does not count any trailing null." to "For symbolic links, the st_mode member shall contain meaningful information when used with the file type macros. The file mode bits in st_mode are unspecified. The structure members st_ino, st_dev, st_uid, st_gid, st_atim, st_ctim, and st_mtim shall have meaningful values and the value of the st_nlink member shall be set to the number of (hard) links to the symbolic link. The value of the st_size member shall bet set to the length of the pathname contained in the symbolic link not including any trailing null." On page 1170 line 39190 section lchown, delete "[EOPNOTSUPP] The path argument names a symbolic link and the implementation does not support setting the owner or group of a symbolic link." On page 1180 line 39471 section link, delete "unless the implementation does not support making hard links to symbolic links in which case the linkat() call shall fail" On page 1181 line 39505 section link, delete "[EOPNOTSUPP] The AT_SYMLINK_FOLLOW flag is clear in the flag argument, the path1 argument names a symbolic link, and the implementation does not support making hard links to symbolic links." On page 1704 line 54608 section readdir, append "The value of the structure's d_ino member shall be set to the file serial number of the file named by the d_name member. If the d_name member names a symbolic link, the value of the d_ino member shall be set to the file serial number of the symbolic link itself." On page 1704 line 54623 section readdir, delete "If the entry names a symbolic link, the value of the d_ino member is unspecified." On page 1706 line 54708 section readdir, insert a new paragraph: "When returning a directory entry for the root of a mounted file system, some historical implementations of readdir() returned the file serial number of the underlying mount point, rather than of the root of the mounted file system. This behavior is considered to be a bug, since the underlying file serial number has no significance to applications." On page 1709 line 54808 section readlink, delete "[EACCES] Read permission is denied for the symbolic link referred to by path." On page 2005 line 63682 section symlink, insert three new paragraphs: "The symbolic link's user ID shall be set to the process' effective user ID. The symbolic link's group ID shall be set to the group ID of the parent directory or to the effective group ID of the process. Implementations shall provide a way to initialize the symbolic link's group ID to the group ID of the parent directory. Implementations may, but need not, provide an implementation-defined way to initialize the symbolic link's group ID to the effective group ID of the calling process. The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-200x shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified. Upon successful completion, symlink() shall mark for update the last data access, last data modification, and last file status change timestamps of the symbolic link. Also, the last data modification and last file status change timestamps of the directory that contains the new entry shall be marked for update." Cross-volume changes to XCU: On page 2789 line 92056 section ls, append "For a symbolic link, the time used as the sort key is that of the symbolic link itself, unless the -H or -L options are specified." On page 2926 line 97400 section pax, delete "except that if the files to be linked are symbolic links and the system is not capable of making hard links to symbolic links, then separate copies of the symbolic link shall be created instead". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 29 gwc:xxxxxxxxxxxxx Bug in XSHd3 futimens (rdvk# 18) [gwc futimens EACCES] Fri, 6 Jul 2007 09:26:04 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 937 Line: 31807 Section: futimens Problem: Two finegrain aardvarks (XSHfg ERN 61 and 69) both modified the same text, and part of one (61) got lost in the process. Action: Change "The times argument is a null pointer and" to "The times argument is a null pointer, or both tv_nsec values are UTIME_NOW, and" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 30 ebb9:xxxxxxx Bug in XSHd3 futimens (rdvk# 2) {ebb.utimensat} Wed, 20 Jun 2007 19:49:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 938 Line: 31880 Section: futimens Problem: The rename of futimesat still has some editorial fixups needed. Action: In XSH, at line 31880, change "futimesat)()" to "futimesat())". In XRAT, at line 124279, under POSIX_FILE_SYSTEM_FD, replace futimesat with utimensat and re-sort the list. _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 gwc:xxxxxxxxxxxxx Bug in XSHd3 getdelim (rdvk# 50) [gwc getdelim EINVAL] Wed, 25 Jul 2007 16:22:48 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 970 Line: 33066 Section: getdelim Problem: The getdelim() page lists the following error related to the stream argument: "[EINVAL] stream is not a valid file descriptor" Apart from the fact that the stream argument is not a "file descriptor", specifying an EINVAL error for a (FILE *) stream argument is inconsistent with the errors listed for other stdio input functions related to the stream argument. The best way to fix the problem would be to use the same approach as the fscanf() page, by adding a reference to the fgetc() page to cover the errors related to the stream, and just listing the additional errors specific to getdelim() and getline() on the getdelim() page. There is also an editorial correction needed to the first EINVAL error. Action: At line 33062 change: "These functions shall fail if:" to: "For the conditions under which the getdelim() and getline() functions shall fail and may fail, refer to [xref to fgetc()]. In addition, these functions shall fail if:" At line 33063 change: "When lineptr or n are a null pointer." to: "lineptr or n is a null pointer." Delete line 33066 (the second EINVAL error). _____________________________________________________________________________ COMMENT Enhancement Request Number 32 vincent-opgr:xxxxxxxxxx Bug in XSHd3 lgamma (rdvk# 37) {0} Thu, 26 Jul 2007 11:48:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: After "The sign of Gamma(x) is returned in the external integer signgam." add "If x is NaN, -Inf or a negative integer, the value of signgam is unspecified." _____________________________________________________________________________ Page: 1178 Line: 39378 Section: lgamma Problem: The description of lgamma() says: "The sign of Gamma(x) is returned in the external integer signgam." But the sign of Gamma(x) is not defined when x is NaN, -Inf or a negative integer. And POSIX doesn't say whether the value is unmodified, it is set to some unspecified sign (-1, 0 or 1) or it is undefined. Action: After "The sign of Gamma(x) is returned in the external integer signgam." add "If x is NaN, -Inf or a negative integer, the value of signgam is undefined." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 33 nick:xxxxxxxxxx Bug in XSHd3 linkat (rdvk# 15) {nms-xref-01} Fri, 6 Jul 2007 17:03:40 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1184 Line: 39606 Section: linkat Problem: The cross reference from linkat to link takes you to XCU link, not to XSH link. Action: Change the xref to refer to the link() function on XSH page 1180 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 34 nick:xxxxxxxxxx Bug in XSHd3 malloc (rdvk# 44) {nms-malloc-seealso} Wed, 25 Jul 2007 21:02:15 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the See Also line with: calloc(), free(), posix_memalign(), realloc(), setrlimit() XBD _____________________________________________________________________________ Page: 1231 Line: 41075 Section: malloc Problem: The "See Also" section for malloc includes "alphasort()" (which doesn't use malloc, though scandir on the same page does). It also calls out fmemopen, but not open_memstream or open_wmemstream, nor scanf, all of which have an interaction with malloc. Also, setrlimit() can be used to limit the amount of memory available for allocation, and mmap() can also reduce the amount of memory available; both of these deserve mention in the see also list (both have details about this interaction on the relevant pages Action: Replace the See Also line with: calloc(), free(), fscanf(), fwscanf(), fmemopen(), mmap(), open_memstream(), open_wmemstream(), posix_memalign(), realloc(), setrlimit(), strdup(), scandir(). XBD _____________________________________________________________________________ COMMENT Enhancement Request Number 35 Michael T Kerrisk BUG in XSHd3 mq_notify (rdvk# 40) Tue, 24 Jul 2007 10:43:24 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1290 Line: 42890 Section: mq_notify Problem: This is an example program for this interface. As discussed with Andrew off list, the example programs I'm submitting come from already published versions in the Linux man pages, and each was written solely by me. I assign a non-exclusive copyright to The Open Group. This is an example program, intended to clarify the use of this interface for the reader of the standard. Page and line numbers refer to draft 3 of the revision. Action: (Suggest also to replace line 42838 (XSH mq_getattr EXAMPLES) with: "See mq_notify().) substitute line 42890 ("None") with the following text: The following program registers a notification request for the message queue named in its command-line argument. Notification is performed by creating a thread. The thread executes a function which reads one message from the queue and then terminates the process. #include #include #include #include #include #include static void /* Thread start function */ tfunc(union sigval sv) { struct mq_attr attr; ssize_t nr; void *buf; mqd_t mqdes = *((mqd_t *) sv.sival_ptr); /* Determine maximum msg size; allocate buffer to receive msg */ if (mq_getattr(mqdes, &attr) == -1) { perror("mq_getattr"); exit(EXIT_FAILURE); } buf = malloc(attr.mq_msgsize); if (buf == NULL) { perror("malloc"); exit(EXIT_FAILURE); } nr = mq_receive(mqdes, buf, attr.mq_msgsize, NULL); if (nr == -1) { perror("mq_receive"); exit(EXIT_FAILURE); } printf("Read %ld bytes from message queue\n", (long) nr); free(buf); exit(EXIT_SUCCESS); /* Terminate the process */ } int main(int argc, char *argv[]) { mqd_t mqdes; struct sigevent not; assert(argc == 2); mqdes = mq_open(argv[1], O_RDONLY); if (mqdes == (mqd_t) -1) { perror("mq_open"); exit(EXIT_FAILURE); } not.sigev_notify = SIGEV_THREAD; not.sigev_notify_function = tfunc; not.sigev_notify_attributes = NULL; not.sigev_value.sival_ptr = &mqdes; /* Arg. to thread func. */ if (mq_notify(mqdes, ¬) == -1) { perror("mq_notify"); exit(EXIT_FAILURE); } pause(); /* Process will be terminated by thread function */ } _____________________________________________________________________________ COMMENT Enhancement Request Number 36 Michael T Kerrisk BUG in XSH (rdvk# 38) Tue, 24 Jul 2007 10:39:52 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (from austin-review-l 2466) #include #include #include #include #include static int display_info(const char *fpath, const struct stat *sb, int tflag, struct FTW *ftwbuf) { printf("%-3s %2d %7jd %-40s %d %s\n", (tflag == FTW_D) ? "d" : (tflag == FTW_DNR) ? "dnr" : (tflag == FTW_DP) ? "dp" : (tflag == FTW_F) ? "f" : (tflag == FTW_NS) ? "ns" : (tflag == FTW_SL) ? "sl" : (tflag == FTW_SLN) ? "sln" : "???", ftwbuf->level, (intmax_t) sb->st_size, fpath, ftwbuf->base, fpath + ftwbuf->base); return 0; /* To tell nftw() to continue */ } int main(int argc, char *argv[]) { int flags = 0; if (argc > 2 && strchr(argv[2], 'd') != NULL) flags |= FTW_DEPTH; if (argc > 2 && strchr(argv[2], 'p') != NULL) flags |= FTW_PHYS; if (nftw((argc < 2) ? "." : argv[1], display_info, 20, flags) == -1) { perror("nftw"); exit(EXIT_FAILURE); } exit(EXIT_SUCCESS); } _____________________________________________________________________________ Page: 1336 Line: 44247-44262 Section: nftw Problem: This is an example program for this interface. As discussed with Andrew off list, the example programs I'm submitting come from already published versions in the Linux man pages, and each was written solely by me. I assign a non-exclusive copyright to The Open Group. This is an example program, intended to clarify the use of this interface for the reader of the standard. Page and line numbers refer to draft 3 of the revision. This example is intended as an improvement of the existing example for this interface. Action: substitute lines 44247-44262 with the following text: The following program traverses the directory tree under the path named in its first command-line argument, or under the current directory if no argument is supplied. It displays various information about each file. The second-command line argument can be used to specify characters that control the value assigned to the flags argument when calling nftw(). #include #include #include #include static int display_info(const char *fpath, const struct stat *sb, int tflag, struct FTW *ftwbuf) { printf("%-3s %2d %7lld %-40s %d %s\n", (tflag == FTW_D) ? "d" : (tflag == FTW_DNR) ? "dnr" : (tflag == FTW_DP) ? "dp" : (tflag == FTW_F) ? "f" : (tflag == FTW_NS) ? "ns" : (tflag == FTW_SL) ? "sl" : (tflag == FTW_SLN) ? "sln" : "???", ftwbuf->level, (long long) sb->st_size, fpath, ftwbuf->base, fpath + ftwbuf->base); return 0; /* To tell nftw() to continue */ } int main(int argc, char *argv[]) { int flags = 0; if (argc > 2 && strchr(argv[2], 'd') != NULL) flags |= FTW_DEPTH; if (argc > 2 && strchr(argv[2], 'p') != NULL) flags |= FTW_PHYS; nftw((argc < 2) ? "." : argv[1], display_info, 20, flags); exit(EXIT_SUCCESS); } _____________________________________________________________________________ OBJECTION Enhancement Request Number 37 nick:xxxxxxxxxx Bug in XSHd3 open (rdvk# 9) {nms-open-01} Fri, 6 Jul 2007 18:44:45 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1345 Line: 44479 Section: open Problem: While this is primarily an editorial change, and out of scope for this ballot because the line has not changed since D2R, I believe this problem was missed at the last ballot and is of sufficient magnitude to require immediate remediation rather than waiting for a TC after publication. I am therefore filing this as an objection. The text for O_NONBLOCK has become elided with the text for O_NOFOLLOW. These are two distinct and separate cases. In TC2, the text said: O_NOCTTY If set and path identifies a terminal device, open() shall not cause the terminal device to become the controlling terminal for the process. O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: ... The new text says: O_NOCTTY If set and path identifies a terminal device, open() shall not cause the terminal device to become the controlling terminal for the process. O_NOFOLLOW If path names a symbolic link, fail and set errno to [ELOOP]. When opening a FIFO with O_RDONLY or O_WRONLY set: ... Action: Break the O_NOFOLLOW line after the first sentence. Add a new list header "O_NONBLOCK". Resulting text should read: O_NOCTTY If set and path identifies a terminal device, open() shall not cause the terminal device to become the controlling terminal for the process. O_NOFOLLOW If path names a symbolic link, fail and set errno to [ELOOP]. O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: ... _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 ebb9:xxxxxxx Bug in XSHd3 open (rdvk# 3) {ebb.open} Wed, 20 Jun 2007 19:10:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_37 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1345 Line: 44479 Section: open Problem: O_NONBLOCK disappeared from the lineup of open options. Also, the change history could be more explicit in documenting that new flags were added as part of Issue 7. Furthermore, O_DIRECTORY and O_NOFOLLOW are not documented in . Action: Add these two lines of file creation flags in sorted order in lines 7708-7711: O_DIRECTORY Require that file be a directory. O_NOFOLLOW Require that file not be a symbolic link. Rewrite the two lines at 44479-44480: O_NOFOLLOW If path names a symbolic link, fail and set errno to [ELOOP]. When opening a FIFO with O_RDONLY or O_WRONLY set: as follows: O_NOFOLLOW If path names a symbolic link, fail and set errno to [ELOOP]. O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: At line 44760, append the following to the paragraph about adding openat: This includes the addition of the flags O_DIRECTORY and O_NOFOLLOW. _____________________________________________________________________________ COMMENT Enhancement Request Number 39 mh-austin:xxxxxx Bug in XSHd3 open (rdvk# 30) [mh2007d3003] Tue, 10 Jul 2007 08:16:02 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1350 Line: 44698-44703 Section: open Problem: The paragraph beginning at line 44698 ("For example ...") is misplaced because it is an example of the issue discussed 3 paragraphs back. To avoid confusion, this example should immediately follow the paragraph describing the corresponding issue, as it did in the 2004 edition. Action: Move lines 44698-44703 immediately after line 44689. _____________________________________________________________________________ OBJECTION Enhancement Request Number 40 ebb9:xxxxxxx Bug in XSHd3 open_memstream (rdvk# 47) {ebb.open_memstream} Wed, 25 Jul 2007 19:29:10 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change from After a successful fflush( ) or fclose( ), the pointer referenced by bufp shall contain the address of the buffer, and the variable pointed to by sizep shall contain the number of bytes for open_memstream( ) or the number of wide characters for open_wmemstream( ), between the beginning of the buffer and the current file position indicator. to After a successful fflush( ) or fclose( ), the pointer referenced by bufp shall contain the address of the buffer, and the variable pointed to by sizep shall contain the smaller of the current buffer length and the number of bytes for open_memstream( ), or the number of wide characters for open_wmemstream( ), between the beginning of the buffer and the current file position indicator. _____________________________________________________________________________ Page: 1352 Line: 44785 Section: open_memstream Problem: In spite of the changes made to open_memstream as part of draft 3, the spec is internally inconsistent. open_memstream requires that the opened stream be seekable (line 44773), fseeko requires that a seekable stream allow the current position to be set beyond the end of a file but that the intermediate data is unspecified unless a write takes place (line 30825), fflush only changes the current position if there is buffered unwritten data, and open_memstream requires that on fflush the variable pointed to by sizep is set to the bytes between the beginning of the buffer and the current position (line 44785). According to the above rules, char *buf; size_t size; FILE *f = open_memstream (&buf, &size); int err = fseeko (f, 2, SEEK_SET); should leave the stream at position 2, even though the end of the file is at position 0. Following this with fflush (f); would imply that buf now points to at least three bytes, size is 2, and buf[2] is 0, but does not state what buf[0] and buf[1] are set to. If it is truly desirable to always set size according to the current file position, then we should specify what the data between EOF and the size is set to. But more likely, this should behave like regular files, where seeking beyond the end of a file then flushing does not change the current position of the stream, but also does not change the size of the file visible to stat - it takes a futher write at the new position to make the visible size change. For comparison, the existing glibc implementation sets err to -1, but fails to set errno; a followup ftello shows that glibc left the current position at 0, basically making it impossible to seek beyond the end of written data. This behavior cannot be standardized (if a function fails, it must set errno), but the question remains as to whether the glibc bug is in failing to set errno, or in failing to seek. The proposed wording assumes that it is desirable to allow seeks beyond the end of a memstream, at which point subsequent writes fill the gap with NUL bytes, by changing the fflush and fclose rules to state that psize is set to the current end of file (ie. buffer length) if the current position exceeds the current end of file. An alternative fix might be rewording fseek/fseeko to forbid seeking beyond the end of a memstream, but that would make memstreams needlessly different from regular file streams. Action: Replace the wording at line 44787: between the beginning of the buffer and the current file position indicator. with: between the beginning of the buffer and the smaller of the current file position indicator and the current buffer length. _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 ebb9:xxxxxxx Bug in XSHd3 psiginfo (rdvk# 32) {ebb.psiginfo} Fri, 20 Jul 2007 19:19:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At line 48541, insert into the psiginfo DESCRIPTION: The psiginfo() and psignal() functions shall mark for update the last data modification and last file status change timestamps of the file associated with the standard error stream at some time between their successful completion and exit(), abort(), or the completion of fflush() or fclose() on stderr. Fix similar text in perror p1363 45023 The perror() function shall mark for update the last data modification and last file status change timestamps of the file associated with the standard error stream at some time between its successful completion and exit(), abort(), or the completion of fflush() or fclose() on stderr. _____________________________________________________________________________ Page: 1491 Line: 48541 Section: psiginfo Problem: The perror function makes it clear that the orientation of stderr is unchanged. A similar specification is lacking for the new psiginfo/psignal interfaces [see the defect raised on XBDd3 3.84]. Further, psiginfo is missing information on how timestamps are affected. Since psiginfo was not edited for draft 3, this change should be considered in light of consistency with other changes, and so that psiginfo does not conflict with the C standard. However, the wording in perror is a bit confusing - if no prior output has been made to the standard error stream, then does perror result in byte or wide character output? And how does it restore stderr back to unspecified orientation (fwide cannot remove orientation, and freopen loses the position)? The proposed wording takes the approach that if stderr is not yet oriented, that the functions in question result in stderr having byte orientation. Action: At line 48541, insert two paragraphs in the psiginfo DESCRIPTION: The psiginfo() and psignal() functions shall mark the file associated with the standard error stream as having been written (the last data modification and last file status change timestamps marked for update) at some time between its successful completion and exit(), abort(), or the completion of fflush() or fclose() on stderr. If the standard error stream has no orientation, the psiginfo() and psignal() functions shall change the stream to byte-orientation; otherwise the functions shall not change the orientation. [Note that the above change overlaps with the one proposed in the defect on XBDd3 3.84] At line 45027, replace the paragraph: The perror() function shall not change the orientation of the standard error stream. with the paragraph: If the standard error stream has no orientation, the perror() function shall change the stream to byte-orientation; otherwise the function shall not change the orientation. _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 gwc:xxxxxxxxxxxxx squonk.masqnet> (rdvk# 48) [gwc pthread may fails] Wed, 25 Jul 2007 15:58:02 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1495 Line: 48676 Section: pthread_attr_destroy Problem: XSH ERN 215 identified a problem with pthread ESRCH errors that also affects several other pthread "may fail" errors. For consistency the same solution should be applied in these other cases. To summarise the problem: the intention of the POSIX.1c developers was that when a "may fail" condition for a pthreads function is caused by "application error", if the implementation chooses not to detect the optional error then the behaviour would be undefined, but in many cases they neglected to state that the behaviour is undefined in normative text. (An explicit statement to that effect was needed because POSIX.1-1990 - the base standard which POSIX.1c amended - stated in section 2.4 "Each implementation shall document, in the conformance document, situations in which each of the optional conditions are detected. If no error condition is detected, the action requested shall be successful." This statement also appeared in POSIX.1-1996, the merged standard which incorporated POSIX.1c.) Note that the changes below do not include changes for the pthread_mutex_getprioceiling, pthread_mutex_lock and pthread_mutex_timedlock pages, which are the subject of a separate aardvark. Also, I have not proposed changes related to the pthread_rwlock_*() EDEADLK errors as the standard already has a clear requirement for two optional behaviours: either deadlock or return an EDEADLK error. The changes are in groups of related errors. E.g. the first group is for thread attribute object EINVAL errors. Where an addition to the end of the DESCRIPTION or RATIONALE sections is specified it may be preferable, for some functions within a group, to add the new text at an earlier location. The editors should feel free to use their discretion here. Action: Delete the following "may fail" EINVAL errors: P1495 L48676 pthread_attr_destroy P1498 L48800 pthread_attr_getdetachstate or pthread_attr_setdetachstate P1500 L48883 pthread_attr_getguardsize or pthread_attr_setguardsize P1503 L48975 pthread_attr_getinheritsched P1503 L48979 (2nd EINVAL for) pthread_attr_setinheritsched P1505 L49043 pthread_attr_getschedparam P1505 L49046 pthread_attr_setschedparam (just "or the value ... object" part) P1507 L49098 pthread_attr_getschedpolicy P1507 L49101 pthread_attr_setschedpolicy (just "or the value ... object" part) P1509 L49159 pthread_attr_getscope P1509 L49162 pthread_attr_setscope (just "or the value ... object" part) P1511 L49228 pthread_attr_getstack P1511 L49232 pthread_attr_setstack (just "or the value ... object" part) P1513 L49301 pthread_attr_getstacksize or pthread_attr_setstacksize P1563 L50573 pthread_create and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name(s) shown above for pthread_attr_destroy): "The behavior is undefined if the value specified by the attr argument to pthread_attr_destroy() does not refer to an initialized thread attributes object." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the attr argument to pthread_attr_destroy() does not refer to an initialized thread attributes object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EBUSY error: P1495 L48679 pthread_attr_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the attr argument to pthread_attr_init() refers to an already initialized thread attributes object, it is recommended that the function should fail and report an EBUSY error." Delete the following "may fail" EBUSY errors: P1524 L49433 pthread_barrier_destroy P1525 L49442 pthread_barrier_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the barrier argument to pthread_barrier_destroy() or pthread_barrier_init() refers to a barrier that is in use (for example, in a pthread_barrier_wait() call) by another thread, or detects that the value specified by the barrier argument to pthread_barrier_init() refers to an already initialized barrier object, it is recommended that the function should fail and report an EBUSY error." Delete the following "may fail" EINVAL errors: P1524 L49436 pthread_barrier_destroy P1526 L49496 pthread_barrier_wait and in each case add the following statements to the end of the subsequent RATIONALE (substituting the function name shown above for pthread_barrier_destroy): "If an implementation detects that the value specified by the barrier argument to pthread_barrier_destroy() does not refer to an initialized barrier object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EINVAL error: P1525 L49445 pthread_barrier_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the attr argument to pthread_barrier_init() does not refer to an initialized barrier attributes object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EINVAL errors: P1528 L49539 pthread_barrierattr_destroy P1530 L49591 pthread_barrierattr_getpshared or pthread_barrierattr_setpshared and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name(s) shown above for pthread_barrierattr_destroy): "The behavior is undefined if the value specified by the attr argument to pthread_barrierattr_destroy() does not refer to an initialized barrier attributes object." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the attr argument to pthread_barrierattr_destroy() does not refer to an initialized barrier attributes object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EINVAL errors: P1541 L49919 pthread_cond_broadcast or pthread_cond_signal P1544 L50036 pthread_cond_destroy and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name(s) shown above for pthread_cond_destroy): "The behavior is undefined if the value specified by the cond argument to pthread_cond_destroy() does not refer to an initialized condition variable." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the cond argument to pthread_cond_destroy() does not refer to an initialized condition variable, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EBUSY errors: P1544 L50033 pthread_cond_destroy P1545 L50042 pthread_cond_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the cond argument to pthread_cond_destroy() or pthread_cond_init() refers to a condition variable that is in use (for example, in a pthread_cond_wait() call) by another thread, or detects that the value specified by the cond argument to pthread_cond_init() refers to an already initialized condition variable, it is recommended that the function should fail and report an EBUSY error." Delete the following "may fail" EINVAL error: P1545 L50045 pthread_cond_init and add the following statement to the end of the preceding DESCRIPTION: "The behavior is undefined if the value specified by the attr argument to pthread_cond_init() does not refer to an initialized condition variable attributes object." and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the attr argument to pthread_cond_init() does not refer to an initialized condition variable attributes object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EINVAL error: P1549 L50195 pthread_cond_timedwait or pthread_cond_wait and add the following statement to the end of the preceding DESCRIPTION: "The behavior is undefined if the value specified by the cond or mutex argument to these functions does not refer to an initialized condition variable or an initialized mutex object, respectively." and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the cond argument to pthread_cond_timedwait() or pthread_cond_wait() does not refer to an initialized condition variable, or detects that the value specified by the mutex argument to pthread_cond_timedwait() or pthread_cond_wait() does not refer to an initialized mutex object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EPERM error: P1549 L50200 pthread_cond_timedwait or pthread_cond_wait and add the following after line 50193: "[EPERM] The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a robust mutex, and the current thread does not own the mutex." Delete the following "may fail" EINVAL errors: P1554 L50386 pthread_condattr_destroy P1556 L50436 pthread_condattr_getclock or pthread_condattr_setclock P1558 L50487 pthread_condattr_getpshared or pthread_condattr_setpshared and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name(s) shown above for pthread_condattr_destroy): "The behavior is undefined if the value specified by the attr argument to pthread_condattr_destroy() does not refer to an initialized condition variable attributes object." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the attr argument to pthread_condattr_destroy() does not refer to an initialized condition variable attributes object, it is recommended that the function should fail and report an EINVAL error." At page 1556 line 50662 section pthread_detach, delete "The effect of multiple pthread_detach() calls on the same target thread is unspecified." Delete the following "may fail" EINVAL errors: P1566 L50669 pthread_detach P1579 L51066 pthread_join and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name shown above for pthread_detach): "The behavior is undefined if the value specified by the thread argument to pthread_detach() does not refer to a joinable thread." and add the following statement to the end of the subsequent RATIONALE (again substituting the function name): "If an implementation detects that the value specified by the thread argument to pthread_detach() does not refer to a joinable thread, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EINVAL errors: P1577 L51013 pthread_setspecific P1585 L51286 pthread_key_delete and in each case add the following statement to the end of the subsequent RATIONALE (substituting the function name shown above for pthread_setspecific): "If an implementation detects that the value specified by the key argument to pthread_setspecific() does not refer to a a key value obtained from pthread_key_create() or refers to a key that has been deleted with pthread_key_delete(), it is recommended that the function should fail and report an EINVAL error." At page 1579 line 51065 section pthread_join, delete: "or the value of thread specifies the calling thread" from the description of the EDEADLK error and add the following statement to the end of the preceding DESCRIPTION: "The behavior is undefined if the value specified by the thread argument to pthread_join() refers to the calling thread." and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the thread argument to pthread_join() refers to the calling thread, it is recommended that the function should fail and report an EDEADLK error." Delete the following "may fail" EINVAL errors: P1589 L51393 pthread_mutex_consistent P1591 L51454 pthread_mutex_destroy and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name shown above for pthread_mutex_destroy): "The behavior is undefined if the value specified by the mutex argument to pthread_mutex_destroy() does not refer to an initialized mutex." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the mutex argument to pthread_mutex_destroy() does not refer to an initialized mutex, it is recommended that the function should fail and report an EINVAL error." At page 1591 line 51429 section pthread_mutex_destroy, change: "Attempting to destroy a locked mutex results in undefined behavior." to: "Attempting to destroy a locked mutex or a mutex that is referenced (for example, while being used in a pthread_cond_timedwait() or pthread_cond_wait()) by another thread results in undefined behavior." Delete the following "may fail" EBUSY errors: P1591 L51451 pthread_mutex_destroy P1592 L51461 pthread_mutex_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the mutex argument to pthread_mutex_destroy() or pthread_mutex_init() refers to a locked mutex or a mutex that is referenced (for example, while being used in a pthread_cond_timedwait() or pthread_cond_wait()) by another thread, or detects that the value specified by the mutex argument to pthread_mutex_init() refers to an already initialized mutex, it is recommended that the function should fail and report an EBUSY error." At page 1592 line 51487 section pthread_mutex_destroy, change: "Many of the error checks were made optional in order to let implementations trade off performance versus degree of error checking according to the needs of their specific applications and execution environment. As a general rule, errors or conditions caused by the system (such as insufficient memory) always need to be reported, but errors due to an erroneously coded application (such as failing to provide adequate synchronization to prevent a mutex from being deleted while in use) are made optional." to: "Many error conditions that can occur are not required to be detected by the implementation in order to let implementations trade off performance versus degree of error checking according to the needs of their specific applications and execution environment. As a general rule, conditions caused by the system (such as insufficient memory) are required to be detected, but conditions caused by an erroneously coded application (such as failing to provide adequate synchronization to prevent a mutex from being deleted while in use) are specified to result in undefined behavior." and append to line 51504: "When the behavior is undefined, no error number is specified to be returned on implementations that do detect the condition. This is because undefined behavior means anything can happen, which includes returning with any value (which might happen to be a valid, but different, error number). However, since the error number might be useful to application writers when diagnosing problems during application development, a recommendation is made in rationale that implementors should return a particular error number if their implementation does detect the condition." Delete the following "may fail" EINVAL errors: P1591 L51463 pthread_mutex_init P1608 L51984 pthread_mutexattr_destroy P1613 L52205 pthread_mutexattr_getprioceiling or pthread_mutexattr_setprioceiling (just the "attr or" part) P1616 L52299 pthread_mutexattr_getprotocol or pthread_mutexattr_setprotocol (just the "attr or" part) P1618 L52361 pthread_mutexattr_getpshared or pthread_mutexattr_setpshared P1620 L52427 pthread_mutexattr_getrobust or pthread_mutexattr_setrobust P1623 L52500 pthread_mutexattr_gettype or pthread_mutexattr_settype and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name(s) shown above for pthread_mutexattr_destroy): "The behavior is undefined if the value specified by the attr argument to pthread_mutexattr_destroy() does not refer to an initialized mutex attributes object." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the attr argument to pthread_mutexattr_destroy() does not refer to an initialized mutex attributes object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EINVAL error: P1630 L52598 pthread_once and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the once_control argument to pthread_once() does not refer to a pthread_once_t object initialized by PTHREAD_ONCE_INIT, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EBUSY errors: P1632 L52691 pthread_rwlock_destroy P1633 L52700 pthread_rwlock_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the rwlock argument to pthread_rwlock_destroy() or pthread_rwlock_init() refers to a locked read-write lock object, or detects that the value specified by the rwlock argument to pthread_rwlock_init() refers to an already initialized read-write lock object, it is recommended that the function should fail and report an EBUSY error." Delete the following "may fail" EINVAL errors: P1632 L52693 pthread_rwlock_destroy P1636 L52791 pthread_rwlock_rdlock or pthread_rwlock_tryrdlock P1638 L52868 pthread_rwlock_timedrdlock (just "The value specified ... object, or" part) P1640 L52926 pthread_rwlock_timedwrlock (just "The value specified ... object, or" part) P1643 L52987 pthread_rwlock_trywrlock or pthread_rwlock_wrlock P1645 L53048 pthread_rwlock_unlock and in each case add the following statement to the end of the subsequent RATIONALE (substituting the function name shown above for pthread_rwlock_destroy): "If an implementation detects that the value specified by the rwlock argument to pthread_rwlock_destroy() does not refer to an initialized read-write lock object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EPERM error: P1645 L53050 pthread_rwlock_unlock and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the rwlock argument to pthread_rwlock_unlock() refers to a read-write lock object for which the current thread does not hold a lock, it is recommended that the function should fail and report an EPERM error." Delete the following "may fail" EINVAL errors: P1633 L52703 pthread_rwlock_init P1648 L53109 pthread_rwlockattr_destroy P1650 L53166 pthread_rwlockattr_getpshared or pthread_rwlockattr_setpshared and in each case add the following statement to the end of the preceding DESCRIPTION (substituting the function name(s) shown above for pthread_rwlockattr_destroy): "The behavior is undefined if the value specified by the attr argument to pthread_rwlockattr_destroy() does not refer to an initialized read-write lock attributes object." and add the following statement to the end of the subsequent RATIONALE (again substituting the function names): "If an implementation detects that the value specified by the attr argument to pthread_rwlockattr_destroy() does not refer to an initialized read-write lock attributes object, it is recommended that the function should fail and report an EINVAL error." Delete the following "may fail" EBUSY error: P1666 L53556 pthread_spin_destroy or pthread_spin_init and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the lock argument to pthread_spin_destroy() or pthread_spin_init() refers to a locked spin lock object, or detects that the value specified by the lock argument to pthread_spin_init() refers to an already initialized spin lock object, it is recommended that the function should fail and report an EBUSY error." Delete the following "may fail" EINVAL errors: P1666 L53559 pthread_spin_destroy P1668 L53600 pthread_spin_lock or pthread_spin_trylock P1670 L53644 pthread_spin_unlock and in each case add the following statement to the end of the subsequent RATIONALE (substituting the function name shown above for pthread_spin_destroy): "If an implementation detects that the value specified by the lock argument to pthread_spin_destroy() does not refer to an initialized spin lock object, it is recommended that the function should fail and report an EINVAL error." At page 1668 line 53602 section pthread_spin_lock, delete: "or the calling thread already holds the lock." from the description of the EDEADLK error and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the lock argument to pthread_spin_lock() refers to a spin lock object for which the calling thread already holds the lock, it is recommended that the function should fail and report an EDEADLK error." Delete the following "may fail" EPERM error: P1670 L53645 pthread_spin_unlock and add the following statement to the end of the subsequent RATIONALE: "If an implementation detects that the value specified by the lock argument to pthread_spin_unlock() refers to a spin lock object for which the current thread does not hold the lock, it is recommended that the function should fail and report an EPERM error." _______________________________________________________________________________ OBJECTION Enhancement Request Number 43 gwc:xxxxxxxxxxxxx Bug in XSHd3 pthread_mutex_getprioceiling (rdvk# 33) [gwc mx_gpceil locking] Fri, 20 Jul 2007 16:21:44 +0100 _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The pthread_mutex_setprioceiling() function shall either lock the mutex if it is unlocked, or block until it can successfully lock the mutex, then it shall change the mutex's priority ceiling and release the mutex. When the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling. The process of locking the mutex need not adhere to the priority protect protocol. If pthread_mutex_setprioceiling() is called while holding the mutex, the result is undefined unless the mutex is of type PTHREAD_MUTEX_RECURSIVE." to "The pthread_mutex_setprioceiling() function shall attempt to lock the mutex as if by a call to pthread_mutex_lock(), except that the process of locking the mutex need not adhere to the priority protect protocol. On acquiring the mutex it shall change the mutex's priority ceiling and then release the mutex as if by a call to pthread_mutex_unlock(). When the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling." Replace the ERRORS section (lines 51661-51668) with: "These functions shall fail if: [EINVAL] The protocol attribute of mutex is PTHREAD_PRIO_NONE. [EPERM] The implementation requires appropriate privileges to perform the operation and the caller does not have appropriate privileges. The pthread_mutex_setprioceiling() function shall fail if: [EAGAIN] The mutex could not be acquired because the maximum number of recursive locks for mutex has been exceeded. [EDEADLK] The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex. [EINVAL] The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling, and the implementation adheres to the priority protect protocol in the process of locking the mutex. [ENOTRECOVERABLE] The mutex is a robust mutex and the state protected by the mutex is not recoverable. [EOWNERDEAD] The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_setprioceiling() call and it is up to the new owner to make the state consistent (see [xref to pthread_mutex_lock() page]). The pthread_mutex_setprioceiling() function may fail if: [EDEADLK] A deadlock condition was detected. [EINVAL] The priority requested by prioceiling is out of range. [EOWNERDEAD] The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent (see [xref to pthread_mutex_lock() page]). These functions shall not return an error code of [EINTR]." On page 1600-1601 line 51763-51822 section pthread_mutex_lock: After line 51763 add a new paragraph: "If mutex does not refer to an initialized mutex object, the behavior of pthread_mutex_lock(), pthread_mutex_trylock(), and pthread_mutex_unlock() is undefined." On line 51775 delete "The mutex is not locked." Replace the EOWNERDEAD description at line 51777 with: "The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent." At line 51783 change: "The current thread does not own the mutex and the mutex is a robust mutex." to: "The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a robust mutex, and the current thread does not own the mutex." Delete lines 51784-51786: "The pthread_mutex_lock(), pthread_mutex_trylock(), and pthread_mutex_unlock() functions may fail if: [EINVAL] The value specified by mutex does not refer to an initialized mutex object." Move the EAGAIN error from line 51787 to the first "shall fail" block (after line 51770). Replace the EOWNERDEAD description at line 51791 with: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent." At line 51794 change: "The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected or the current thread already owns the mutex." to: "The pthread_mutex_lock() function shall fail if: [EDEADLK] The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex. The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected." Delete lines 51797-51798: "The pthread_mutex_unlock() function may fail if: [EPERM] The current thread does not own the mutex." At line 51822 append a new paragraph to RATIONALE: "If an implementation detects that the value specified by the mutex argument does not refer to an initialized mutex object, it is recommended that the function should fail and report an EINVAL error." On page 1604-1605 line 51895-51935 section pthread_mutex_timedlock: After line 51895 add a new paragraph: "If mutex does not refer to an initialized mutex object, the behavior is undefined." After line 51900 add: "[EDEADLK] The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex." On line 51908 delete "The mutex is not locked." Replace the EOWNERDEAD description at line 51910 with: "The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent." Delete line 51915: "[EINVAL] The value specified by mutex does not refer to an initialized mutex object." Move the EAGAIN error from line 51916 to the "shall fail" block (after line 51900). At line 51918 change: "[EDEADLK] A deadlock condition was detected or the current thread already owns the mutex." to: "[EDEADLK] A deadlock condition was detected." Replace the EOWNERDEAD description at line 51921 with: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent." At line 51935 change the RATIONALE from: "None" to "Refer to [xref to pthread_mutex_lock()]." On page 1549 line 50188 section pthread_cond_timedwait, change: "[ENOTRECOVERABLE] The state protected by the mutex is not recoverable. The mutex is not locked. [EOWNERDEAD] The mutex is a robust mutex and the process containing the previous owner thread terminated while holding the mutex lock. The mutex lock has been acquired and it is up to the new owner to make the state consistent." to: "These functions shall fail if: [ENOTRECOVERABLE] The state protected by the mutex is not recoverable. [EOWNERDEAD] The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent." On page 1549 line 50197 section pthread_cond_timedwait, change: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock has been acquired and it is up to the new owner to make the state consistent." to: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the calling thread and it is up to the new owner to make the state consistent." _______________________________________________________________________________ Page: 1596 Line: 51648 Section: pthread_mutex_getprioceiling Problem: Since pthread_mutex_setprioceiling() locks the mutex, changes are needed to its description for consistency with additions to pthread_mutex_lock() such as the behaviour for robust mutexes when the owner has terminated. Also the current description does not properly account for all of the various mutex types. For example, if the mutex type is PTHREAD_MUTEX_ERRORCHECK, detecting EDEADLK should be mandated. Rather than repeat all the details about robust mutexes and mutex types from the pthread_mutex_lock() page, it would be simpler to use "as if" in the description. However, the ERRORS section needs to remain separate as there are subtle differences. In addition to needing ENOTRECOVERABLE and EOWNERDEAD added for robust mutexes, there are some other inconsistencies in the ERRORS section on this page: 1. Some of the errors listed under "These functions ..." only apply to pthread_mutex_setprioceiling(). 2. The EAGAIN error that can occur when locking recursive mutexes is missing. 3. The description of pthread_mutex_setprioceiling() states that when it locks the mutex, it "need not adhere to the priority protect protocol". For implementations where it does adhere to the priority protect protocol, the associated EINVAL error should be specified, as per the pthread_mutex_lock() page, 4. The EDEADLK error does not include the condition "A deadlock condition was detected". While copying the text for the missing errors from the pthread_mutex_lock() page I also noticed some problems on that page: 1. The EAGAIN error is listed as applying to pthread_mutex_unlock(). 2. EAGAIN should be a "shall fail" error, not "may fail". 3. The EOWNERDEAD conditions are phrased in terms of the state after the call, not the state on entry to the call. This also applies to other functions that return EOWNERDEAD. 4. The ENOTRECOVERABLE error should not say "The mutex is not locked". This is normal on failure; if we say it for one error we would have to say it for all of them (except EOWNERDEAD). This also applies to other functions that return ENOTRECOVERABLE. Numbers 2-4 also apply to the pthread_mutex_timedlock() page. Finally, some of the "may fail" errors (on all 3 pages) have the same issue as the optional pthread*() ESRCH errors that are being removed by XSH ERN 215. However, there is one difference, which is that some of the errors are mandated for mutexes of type PTHREAD_MUTEX_ERRORCHECK. Therefore instead of removing these errors as was done for ESRCH, they should be turned into "shall fail" errors specifically for PTHREAD_MUTEX_ERRORCHECK mutexes. Action: Change "The pthread_mutex_setprioceiling() function shall either lock the mutex if it is unlocked, or block until it can successfully lock the mutex, then it shall change the mutex's priority ceiling and release the mutex. When the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling. The process of locking the mutex need not adhere to the priority protect protocol. If pthread_mutex_setprioceiling() is called while holding the mutex, the result is undefined unless the mutex is of type PTHREAD_MUTEX_RECURSIVE." to "The pthread_mutex_setprioceiling() function shall attempt to lock the mutex as if by a call to pthread_mutex_lock(), except that the process of locking the mutex need not adhere to the priority protect protocol. On acquiring the mutex it shall change the mutex's priority ceiling and then release the mutex as if by a call to pthread_mutex_unlock(). When the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling." Replace the ERRORS section (lines 51661-51668) with: "These functions shall fail if: [EINVAL] The protocol attribute of mutex is PTHREAD_PRIO_NONE. [EPERM] The implementation requires appropriate privileges to perform the operation and the caller does not have appropriate privileges. The pthread_mutex_setprioceiling() function shall fail if: [EAGAIN] The mutex could not be acquired because the maximum number of recursive locks for mutex has been exceeded. [EDEADLK] The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex. [EINVAL] The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling, and the implementation adheres to the priority protect protocol in the process of locking the mutex. [ENOTRECOVERABLE] The mutex is a robust mutex and the state protected by the mutex is not recoverable. [EOWNERDEAD] The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_setprioceiling() call and it is up to the new owner to make the state consistent (see [xref to pthread_mutex_lock() page]). The pthread_mutex_setprioceiling() function may fail if: [EDEADLK] A deadlock condition was detected. [EINVAL] The priority requested by prioceiling is out of range. [EOWNERDEAD] The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_setprioceiling() call and it is up to the new owner to make the state consistent (see [xref to pthread_mutex_lock() page]). These functions shall not return an error code of [EINTR]." On page 1600-1601 line 51763-51822 section pthread_mutex_lock: After line 51763 add a new paragraph: "If mutex does not refer to an initialized mutex object, the behavior of pthread_mutex_lock(), pthread_mutex_trylock(), and pthread_mutex_unlock() is undefined." On line 51775 delete "The mutex is not locked." Replace the EOWNERDEAD description at line 51777 with: "The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_lock() or pthread_mutex_trylock() call and it is up to the new owner to make the state consistent." At line 51783 change: "The current thread does not own the mutex and the mutex is a robust mutex." to: "The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a robust mutex, and the current thread does not own the mutex." Delete lines 51784-51786: "The pthread_mutex_lock(), pthread_mutex_trylock(), and pthread_mutex_unlock() functions may fail if: [EINVAL] The value specified by mutex does not refer to an initialized mutex object." Move the EAGAIN error from line 51787 to the first "shall fail" block (after line 51770). Replace the EOWNERDEAD description at line 51791 with: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_lock() or pthread_mutex_trylock() call and it is up to the new owner to make the state consistent." At line 51794 change: "The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected or the current thread already owns the mutex." to: "The pthread_mutex_lock() function shall fail if: [EDEADLK] The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex. The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected." Delete lines 51797-51798: "The pthread_mutex_unlock() function may fail if: [EPERM] The current thread does not own the mutex." At line 51822 append a new paragraph to RATIONALE: "If an implementation detects that the value specified by the mutex argument does not refer to an initialized mutex object, it is recommended that the function should fail and report an EINVAL error." On page 1604-1605 line 51895-51935 section pthread_mutex_timedlock: After line 51895 add a new paragraph: "If mutex does not refer to an initialized mutex object, the behavior is undefined." After line 51900 add: "[EDEADLK] The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex." On line 51908 delete "The mutex is not locked." Replace the EOWNERDEAD description at line 51910 with: "The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_timedlock() call and it is up to the new owner to make the state consistent." Delete line 51915: "[EINVAL] The value specified by mutex does not refer to an initialized mutex object." Move the EAGAIN error from line 51916 to the "shall fail" block (after line 51900). At line 51918 change: "[EDEADLK] A deadlock condition was detected or the current thread already owns the mutex." to: "[EDEADLK] A deadlock condition was detected." Replace the EOWNERDEAD description at line 51921 with: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_mutex_timedlock() call and it is up to the new owner to make the state consistent." At line 51935 change the RATIONALE from: "None" to "Refer to [xref to pthread_mutex_lock()]." On page 1549 line 50188 section pthread_cond_timedwait, change: "[ENOTRECOVERABLE] The state protected by the mutex is not recoverable. The mutex is not locked. [EOWNERDEAD] The mutex is a robust mutex and the process containing the previous owner thread terminated while holding the mutex lock. The mutex lock has been acquired and it is up to the new owner to make the state consistent." to: "These functions shall fail if: [ENOTRECOVERABLE] The state protected by the mutex is not recoverable. [EOWNERDEAD] The mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_cond_timedwait() or pthread_cond_wait() call and it is up to the new owner to make the state consistent." On page 1549 line 50197 section pthread_cond_timedwait, change: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock has been acquired and it is up to the new owner to make the state consistent." to: "The mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. The mutex lock shall be acquired by the pthread_cond_timedwait() or pthread_cond_wait() call and it is up to the new owner to make the state consistent." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 44 nick:xxxxxxxxxx Bug in XSHd3 pthread_mutex_lock (rdvk# 42) {nms-mutex-rationale} Sat, 28 Jul 2007 00:49:48 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1601 Line: 51821 Section: pthread_mutex_lock Problem: The Rationale section for pthread_mutex_lock() says "For further rationale on the extended mutex types, see the Rationale (Informative) volume of POSIX.1-200x." A cross reference to the relevant place would make it easier to locate this rationale. Action: Change "For further rationale on the extended mutex types, see the Rationale (Informative)volume of POSIX.1-200x." to "For further rationale on the extended mutex types, see Threads Extensions header, the behavior is undefined." The first part of the change has been made, but the change from "implementation-defined" to "undefined" has not. (The term "implementation-defined" is not appropriate here, as XBDd3 section 1.5 says that when a value or behaviour is implementation-defined, "the implementor shall document such a value or behavior so that it can be used correctly by an application", but passing a non-null resolved_name to realpath() when PATH_MAX is not defined as a constant in is not a correct use of realpath() no matter what the implementor might put in the documentation.) Action: Change "implementation-defined" to "undefined". _____________________________________________________________________________ COMMENT Enhancement Request Number 47 Michael T Kerrisk BUG in XSH (rdvk# 45) Tue, 24 Jul 2007 10:40:33 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1785 Line: 57162 Section: sig_timedwait Problem: This is an example program for this interface. As discussed with Andrew off list, the example programs I'm submitting come from already published versions in the Linux man pages, and each was written solely by me. I assign a non-exclusive copyright to The Open Group. This is an example program, intended to clarify the use of this interface for the reader of the standard. Page and line numbers refer to draft 3 of the revision. Action: (Suggested: under sem_post(), page 1782, line 57099, substitute "None" by "See sem_timedwait()"). substitute line 57162 ("None") with the following text: The program shown below operates on an unnamed semaphore. The program expects two command-line arguments. The first argument specifies a seconds value that is used to set an alarm timer to generate a SIGALRM signal. This handler performs a sem_post(3) to increment the semaphore that is being waited on in main() using sem_timedwait(). The second command-line argument specifies the length of the timeout, in seconds, for sem_timedwait(). #include #include #include #include #include #include #include #include sem_t sem; static void handler(int sig) { write(STDOUT_FILENO, "sem_post() from handler\n", 24); if (sem_post(&sem) == -1) { write(STDERR_FILENO, "sem_post() failed\n", 18); _exit(EXIT_FAILURE); } } int main(int argc, char *argv[]) { struct sigaction sa; struct timespec ts; int s; if (argc != 3) { fprintf(stderr, "Usage: %s \n", argv[0]); exit(EXIT_FAILURE); } if (sem_init(&sem, 0, 0) == -1) { perror("sem_init"); exit(EXIT_FAILURE); } /* Establish SIGALRM handler; set alarm timer using argv[1] */ sa.sa_handler = handler; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; if (sigaction(SIGALRM, &sa, NULL) == -1) { perror("sigaction"); exit(EXIT_FAILURE); } alarm(atoi(argv[1])); /* Calculate relative interval as current time plus number of seconds given argv[2] */ if (clock_gettime(CLOCK_REALTIME, &ts) == -1) { perror("clock_gettime"); exit(EXIT_FAILURE); } ts.tv_sec += atoi(argv[2]); printf("main() about to call sem_timedwait()\n"); while ((s = sem_timedwait(&sem, &ts)) == -1 && errno == EINTR) continue; /* Restart if interrupted by handler */ /* Check what happened */ if (s == -1) { if (errno == ETIMEDOUT) printf("sem_timedwait() timed out\n"); else perror("sem_timedwait"); } else printf("sem_timedwait() succeeded\n"); exit((s == 0) ? EXIT_SUCCESS : EXIT_FAILURE); } -- Michael Kerrisk mtk-lists:xxxxxxx Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser _____________________________________________________________________________ EDITORIAL Enhancement Request Number 48 ebb9:xxxxxxx Bug in XSHd3 signgam (rdvk# 54) {ebb.signgam} Sat, 4 Aug 2007 00:09:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1894 Line: 60560 Section: signgam Problem: XSH should include a placeholder page for signgam, since it does not sort anywhere near its description in lgamma. Action: Between signbit and the sigpause placeholder, at line 60560, add a placeholder page for signgam that redirects to lgamma. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 49 gwc:xxxxxxxxxxxxx Bug in XSHd3 tmpfile (rdvk# 23) [gwc tmpfile EMFILE] Fri, 6 Jul 2007 09:46:42 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2069 Line: 65714 Section: tmpfile Problem: The new EMFILE error needs CX shading. Action: Add CX shading. _____________________________________________________________________________ OBJECTION Enhancement Request Number 50 ebb9:xxxxxxx Bug in XSHd3 vfprintf (rdvk# 4) {ebb.vdprintf} Mon, 18 Jun 2007 20:13:27 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In XBD page 336 line 11693, insert: int vdprintf(int, const char *, va_list); In XBD page 337 line 11734, add dprintf to the list of functions added. In XSH page 2118 line 66975, rewrite the line as: vdprintf, vfprintf, vprintf, vsnprintf, vsprintf format output of a stdarg argument list In XSH page 2118 line 66979, insert: int vdprintf(int filedes, const char *format, va_list ap); In XSH page 2118 line 66988, rewrite the paragraph as: The vdprintf( ), vprintf( ), vfprintf( ), vsnprintf( ), and vsprintf( ) functions shall be equivalent to dprintf( ), printf( ), fprintf( ), snprintf( ), and sprintf( ) respectively, except that instead of being called with a variable number of arguments, they are called with an argument list as defined by . In XSH page 2118 line 67014, add: Issue 7 The vdprintf( ) function is added to complement the dprintf() function from The Open Group Technical Standard, 2006, Extended API Set Part 1. Add to XSH page 494 section 2.9.x May occur cancellation list vdprintf Add vdprintf to XRAT page 3394 new functions list Add vdprintf to XRAT page 3608 appendix E line 124250 POSIX_DEVICE_IO_EXT Add a new ptr page _____________________________________________________________________________ Page: 2118 Line: 66978 Section: vfprintf Problem: dprintf was added as part of Extended API Set Part 1, but it appears to be oversight that a corresponding vdprintf was not added. For symmetry with all other standardized *printf functions, the va_list variant vdprintf should be required with CX shading as the counterpart to dprintf. Action: In XBD page 336 line 11693, insert: int vdprintf(int, const char *, va_list); In XBD page 337 line 11734, add dprintf to the list of functions added. In XSH page 2118 line 66975, rewrite the line as: vdprintf, vfprintf, vprintf, vsnprintf, vsprintf format output of a stdarg argument list In XSH page 2118 line 66979, insert: int vdprintf(int filedes, const char *format, va_list ap); In XSH page 2118 line 66988, rewrite the paragraph as: The vdprintf( ), vprintf( ), vfprintf( ), vsnprintf( ), and vsprintf( ) functions shall be equivalent to dprintf( ), printf( ), fprintf( ), snprintf( ), and sprintf( ) respectively, except that instead of being called with a variable number of arguments, they are called with an argument list as defined by . In XSH page 2118 line 67014, add: Issue 7 The vdprintf( ) function is added from The Open Group Technical Standard, 2006, Extended API Set Part 1. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 51 gwc:xxxxxxxxxxxxx Bug in XSHd3 wait (rdvk# 16) [gwc wait ex2] Mon, 16 Jul 2007 12:00:42 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2135 Line: 67439 Section: wait Problem: Wrong indentation. Action: Reduce the indentation for lines 67439-67442 so that it is the same as the lines before and after them. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 52 gwc:xxxxxxxxxxxxx Bug in XSHd3 waitid (rdvk# 28) [gwc waitid ch] Mon, 16 Jul 2007 12:01:24 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2140 Line: 67663 Section: waitid Problem: Inaccurate change history. Action: Change "recommending that the waitid() function not be used" to "recommending that the waitid() function not be used with idtype equal to P_ALL" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 53 mh-austin:xxxxxx Bug in XSHd3 write (rdvk# 31) [mh2007d304] Tue, 10 Jul 2007 08:29:29 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2214 Line: 69732-69743 Section: write Problem: The OB XSR shading ends prematurely in the middle of the write() STREAMS discussion. Action: Extend OB XSR shading through line 69743. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 54 mh-austin:xxxxxx Bug in XSHd3 write (rdvk# 14) [mh2007d305] Tue, 10 Jul 2007 08:31:14 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2215 Line: 69801,69802 Section: write Problem: Because pwrite() no longer depends on XSI, these lines should not be XSI shaded. Action: Remove XSI shading. _____________________________________________________________________________ OBJECTION Enhancement Request Number 55 ebb.getdelim Bug in XSHd3 getdelim (rdvk# nn) [rdvk123] Wed, 5 Sep 2007 08:31:14 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At line 33050, replace: If *n is non-zero, the application shall ensure that *lineptr points to an object of size at least *n bytes. with: If *n is non-zero, the application shall ensure that *lineptr either points to an object of size at least *n bytes, or is a null pointer. At line 33052, replace: The size of the object pointed to by *lineptr shall be increased to fit the incoming line, if it isn't already large enough. The characters read shall be stored in the string pointed to by the lineptr argument. with: The size of the object pointed to by *lineptr shall be increased to fit the incoming line, if it isn't already large enough, including room for the delimiter and a terminating NUL. The characters read, including any delimiter, shall be stored in the string pointed to by the lineptr argument, and a terminating NUL added when the delimiter or end of file is encountered. At line 33056, add a new paragraph: The getdelim( ) and getline( ) functions may mark the last data access timestamp of the file associated with stream for update. The last data access timestamp shall be marked for update by the first successful execution of fgetc( ), fgets( ), fread( ), fscanf( ), getc( ), getchar( ), getdelim( ), getline( ), gets( ), or scanf( ) using stream that returns data not supplied by a prior call to ungetc( ). At line 33058, replace: Upon successful completion, the getdelim( ) function shall return the number of characters written into the buffer, including the delimiter character if one was encountered before EOF. Otherwise, it shall return −1 and set errno to indicate the error. with: Upon successful completion, the getline( ) and getdelim( ) functions shall return the number of characters written into the buffer, including the delimiter character if one was encountered before EOF, but excluding the terminating NUL character. If no characters were read, and the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream shall be set and the function shall return -1. If an error occurs, the error indicator for the stream shall be set, and the function shall return −1 and set errno to indicate the error. Insert prior to line 33085: if (ferror(fp)) { /* handle error */ } At line 33091, add two new paragraphs: The ferror( ) or feof( ) functions should be used to distinguish between an error condition and an end-of-file condition. Although a NUL terminator is always supplied after the line, note that strlen(*lineptr) will be smaller than the return value if the line contains embedded NUL characters. For each of the following functions, add getdelim( ) and getline( ) to the list of functions that may modify the last data access timestamp: fgetc: line 27711 (3rd line) fgets: line 27832 (3rd line) fread: line 30033 (3rd line) fscanf: line 30725 (3rdline) gets: line 35032 (3rdline) _____________________________________________________________________________ #page 970 line 33049 section getdelim objection {ebb.getdelim} Problem: The proposed specification for getline/getdelim is not consistent with existing practice on trailing NULs, or when *lineptr is NULL but *n is uninitialized. Additionally, the documentation is not clear about the behavior when end-of-file is reached. Finally, the impact on atime should be explicit. Action: At line 33050, replace: If *n is non-zero, the application shall ensure that *lineptr points to an object of size at least *n bytes. with: If *n is non-zero, the application shall ensure that *lineptr either points to an object of size at least *n bytes, or is a null pointer. At line 33052, replace: The size of the object pointed to by *lineptr shall be increased to fit the incoming line, if it isn't already large enough. The characters read shall be stored in the string pointed to by the lineptr argument. with: The size of the object pointed to by *lineptr shall be increased to fit the incoming line, if it isn't already large enough, including room for the delimiter and a terminating NUL. The characters read, including any delimiter, shall be stored in the string pointed to by the lineptr argument, and a terminating NUL added when the delimiter or end of file is encountered. At line 33056, add a new paragraph: The getdelim( ) and getline( ) functions may mark the last data access timestamp of the file associated with stream for update. The last data access timestamp shall be marked for update by the first successful execution of fgetc( ), fgets( ), fread( ), fscanf( ), getc( ), getchar( ), getdelim( ), getline( ), gets( ), or scanf( ) using stream that returns data not supplied by a prior call to ungetc( ). At line 33058, replace: Upon successful completion, the getdelim( ) function shall return the number of characters written into the buffer, including the delimiter character if one was encountered before EOF. Otherwise, it shall return −1 and set errno to indicate the error. with: Upon successful completion, the getline( ) and getdelim( ) functions shall return the number of characters written into the buffer, including the delimiter character if one was encountered before EOF, but excluding the terminating NUL character. If no characters were read, and the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream shall be set and the function shall return -1. If an error occurs, the error indicator for the stream shall be set, and the function shall return −1 and set errno to indicate the error. Insert prior to line 33085: if (ferror(fp)) { /* handle error */ } At line 33091, add two new paragraphs: The ferror( ) or feof( ) functions must be used to distinguish between an error condition and an end-of-file condition. Although a NUL terminator is always supplied after the line, note that strlen(*lineptr) will be smaller than the return value if the line contains embedded NUL characters. For each of the following functions, add getdelim( ) and getline( ) to the list of functions that may modify the last data access timestamp: fgetc: line 27711 fgets: line 27832 fread: line 30033 fscanf: line 30725 gets: line 35032