XSH Draft 2R Aardvark Report Austin-351 Page 1 of 1 Submitted by Andrew Josey, The Open Group. March 16, 2007 Aardvark Summary Table ______________________ ERN 1 Accept ERN 2 Accept ERN 3 Accept ERN 4 Accept ERN 5 Accept as marked ERN 6 Accept ERN 7 Dup of FG-rdvk ERN 8 Accept ERN 9 Accept ERN 10 Accept ERN 11 Accept ERN 12 Accept ERN 13 Accept ERN 14 Accept ERN 15 Accept as marked ERN 16 Accept ERN 17 Accept ERN 18 Accept ERN 19 Accept as marked ERN 20 Accept ERN 21 Reject ERN 22 Accept ERN 23 Accept ERN 24 Accept as marked ERN 25 Accept as marked ERN 26 Accept ERN 27 Accept ERN 28 Accept as marked ERN 29 Accept ERN 30 Accept ERN 31 Accept ERN 32 Accept as marked ERN 33 Accept ERN 34 Reject ERN 35 OPEN ERN 36 Accept ERN 37 Accept ERN 38 Accept as marked ERN 39 Accept ERN 40 Accept ERN 41 Accept ERN 42 Accept as marked ERN 43 Accept ERN 44 Accept as marked ERN 45 Accept ERN 46 Accept ERN 47 Accept ERN 48 Accept ERN 49 Accept as marked ERN 50 Accept ERN 51 Accept ERN 52 Accept ERN 53 Accept ERN 54 Accept ERN 55 Accept ERN 56 Accept ERN 57 Accept ERN 58 Accept ERN 59 Accept ERN 60 Accept ERN 61 Accept ERN 62 Accept ERN 63 Accept ERN 64 Accept ERN 65 Accept ERN 66 Accept ERN 67 Accept _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 60) [LANG, JR, KENNETH #44] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 10 Line: 367 Section: none Problem: IEEE ballot ID 2386400023 Vote Approve reference to Chapter 3 has no page reference (in XSH Document) Action: Should read "Chapter 3 (on page 85)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 2 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 59) [LANG, JR, KENNETH #45] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 14 Line: 475 Section: none Problem: IEEE ballot ID 2386500023 Vote Approve reference to Section 2.1 has no page reference (in XSH Document) Action: Should read "Section 2.1 (on page 13)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 58) [LANG, JR, KENNETH #46] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 14 Line: 482 Section: none Problem: IEEE ballot ID 2386600023 Vote Approve reference to Section 2.2.1.1 has no page reference (in XSH Document) Action: Should read "Section 2.2.1.1 (on page 14)" _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 gwc:xxxxxxxxxxxxx Bug in XSHd2 2.2.2 (rdvk# 14) [gwc poll symbolic constants] Wed, 6 Dec 2006 15:42:29 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 18 Line: 611 Section: 2.2.2 Problem: Header macro/constant confusion. See XBDd2 aardvark ref [gwc symbolic constant def] and the austin-group-l thread starting at mail sequence 9896. Action: Move the entry from the table on page 18 to the table on page 16. _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 gwc:xxxxxxxxxxxxx Bug in XSHd2 2.4.3 (rdvk# 20) [gwc signal term] Thu, 21 Dec 2006 11:25:15 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As below except modify the change for 1189 After line 1189 add a new paragraph: "If the default action is to terminate the process abnormally, the process is terminated as if by a call to _exit() except that the status made available to wait(), waitid(), and waitpid() indicates abnormal termination by the signal. [XSI]If the default action is to terminate the process abnormally with additional actions, implementation-defined abnormal termination actions, such as creation of a core file, may also occur.[/XSI]" Also on XSH page 23 ECHILD the list wait() and waitpid() needs to also include waitid(). This needs to be repeated elsewhere! _____________________________________________________________________________ Page: 31 Line: 1189-1198 Section: 2.4.3 Problem: Section 2.4.3 Signal Actions does not describe, under the SIG_DFL heading, what happens when a signal is delivered whose default action is to terminate the process. Instead the behaviour is described on the page under the table of signals. One consequence of this is that, since the table does not include the SIGRTMIN-SIGRTMAX signals, a possible interpretation is that the requirements stated after the table do not apply to those signals. Because of this, and because section 2.4.3 is where the reader would naturally expect to find the information, the relevant text should be moved to section 2.4.3 and the page should just contain a reference to that location. For completeness, there should also be a statement in section 2.4.3 about what happens when the default action is for the signal to be ignored. Action: After line 1189 add a new paragraph: "If the default action is to terminate the process abnormally, the process is terminated as if by a call to _exit() except that the status made available to wait() and waitpid() indicates abnormal termination by the signal. [XSI]If the default action is to terminate the process abnormally with additional actions, implementation-defined abnormal termination actions, such as creation of a core file, may also occur.[/XSI]" At line 1198 insert: "If the default action is to ignore the signal, delivery of the signal shall have no effect on the process." Cross-volume change to XBD page 309 line 10853 section : Change "T Abnormal termination of the process. The process is terminated as if by a call to _exit() except that the status made available to wait() and waitpid() indicates abnormal termination by the specified signal. A Abnormal termination of the process. [XSI]Additionally, implementation-defined abnormal termination actions, such as creation of a core file, may occur.[/XSI]" I Ignore the signal. S Stop the process. C Continue the process, if it is stopped; otherwise, ignore the signal." to "T Abnormal termination of the process. A Abnormal termination of the process [XSI]with additional actions[/XSI]. I Ignore the signal. S Stop the process. C Continue the process, if it is stopped; otherwise, ignore the signal. The effects on the process in each case are described in the System Interfaces volume of IEEE Std 1003.1-200x, Section 2.4.3 Signal Actions." _____________________________________________________________________________ COMMENT Enhancement Request Number 6 drepper:xxxxxxxxxx Bug in XSHd2 Signal Concepts (rdvk# 32) {ud-at-signal} Thu, 1 Feb 2007 07:01:01 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 33 Line: 1278 Section: Signal Problem: The list of signal-safe functions now contains mknodat() but it never contained mknod(). Now, it makes not much sense to have mkfifo() and mkdir() but not mknod(). So, instead of removing mknodat() it might be better to also add mknod(). Action: Add in the table on XSH page 33, lines 1269 to 1295: mknod() _____________________________________________________________________________ COMMENT Enhancement Request Number 7 drepper:xxxxxxxxxx Bug in XSHd2 Signal Concepts (rdvk# 33) {ud-at-signal2} Thu, 1 Feb 2007 07:01:01 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_FG-rdvk Reject_____ Rationale for rejected or partial changes: See separate rdvk report for finegrain issues _____________________________________________________________________________ Page: 33 Line: 1292 Section: Signal Problem: The list of signal safe functions contains utime() but not utimes() nor the new futimesat(). Given that we keep utimes() and futimesat() and hopefully remove utime() (see anothe raardvark of mine) I suggest adding the two interfaces. Action: Add in the table on XSH page 33, lines 1269 to 1295: futimesat() utimes() _____________________________________________________________________________ EDITORIAL Enhancement Request Number 8 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 57) [LANG, JR, KENNETH #47] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 2186 Section: none Problem: IEEE ballot ID 2386700023 Vote Approve reference to "Scheduling Policies" has no page reference (in XSH Document) Action: Should read "Scheduling Policies (on page 44)" _____________________________________________________________________________ COMMENT Enhancement Request Number 9 drepper:xxxxxxxxxx Bug in XSHd2 Signal Concepts (rdvk# 34) {ud-at-thread} Thu, 1 Feb 2007 07:01:01 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 59 Line: 2393 Section: Threads Problem: The list of atomic file operations includes readlink() and symlink() but not readlinkat() and symlinkat(). Action: Add in the table on XSH page 59, lines 2392 to 2399: readlinkat() symlinkat() _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 56) [LANG, JR, KENNETH #48] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 64 Line: 2632 Section: none Problem: IEEE ballot ID 2386800023 Vote Approve reference to Table 2-1 has no page reference (in XSH Document) Action: Should read "Table 2-1 (on page 65)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 11 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 55) [LANG, JR, KENNETH #49] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 65 Line: 2636 Section: none Problem: IEEE ballot ID 2386900023 Vote Approve reference to Table 2-2 has no page reference (in XSH Document) Action: Should read "Table 2-2 (on page 65)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 12 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 54) [LANG, JR, KENNETH #50] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 78 Line: 3222 Section: none Problem: IEEE ballot ID 2387000023 Vote Approve reference to Table 3-2 has no page reference (in XSH Document) Action: Should read "Table 3-2 (on page 65)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 13 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 53) [LANG, JR, KENNETH #51] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 80 Line: 3266 Section: none Problem: IEEE ballot ID 2387100023 Vote Approve reference to Table 2-6 has no page reference (in XSH Document) Action: Should read "Table 2-6 (on page 80)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 14 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 52) [LANG, JR, KENNETH #52] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 80 Line: 3289 Section: none Problem: IEEE ballot ID 2387200023 Vote Approve reference to Table 2-7 has no page reference (in XSH Document) Action: Should read "Table 2-7 (on page 81)" _____________________________________________________________________________ OBJECTION Enhancement Request Number 15 gwc:xxxxxxxxxxxxx Bug in XSHd2 2.12.3 (rdvk# 13) [gwc pointer conversion] Wed, 3 Jan 2007 15:26:45 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "Conforming implementations shall support conversion of pointers of any type to void * and back without loss of information." to "All function pointer types shall have the same representation as the type pointer to void. Conversion of a function pointer to void * shall not alter the representation. A void * value resulting from such a conversion can be converted back to the original function pointer type, using an explicit cast, without loss of information." _____________________________________________________________________________ Page: 83 Line: 3399-3400 Section: 2.12.3 Problem: Draft 2 added section 2.12.3 Pointer Types, stating: "Conforming implementations shall support conversion of pointers of any type to void * and back without loss of information." The addition was made so that when a void * pointer returned by dlsym() relates to a function, it can be converted into a function pointer in order for the application to make use of the function. However, as a result of interpretation AI-003 the dlsym() page effectively deprecates such conversions by stating in the rationale that they cause compiler warnings, and giving example code that uses dlsym() differently: int *iptr, (*fptr)(int); [...] *(void **)(&fptr) = dlsym(handle, "my_function"); Interpretation AI-003 states that this code "does not generate compiler warnings and will work correctly on all systems supporting the X/Open System Interfaces Extension." The problem is that section 2.12.3 is not sufficient to ensure this code will work. The code does not convert a void * pointer to a function pointer (which is what 2.12.3 guarantees will work), it writes a void * pointer value at the address of a function pointer. If we want to require implementations to support this code, then either 2.12.3 or the dlsym() page needs to make some additional requirements. Below I have suggested a change to 2.12.3 which would require function pointers to have the same representation as void *, with requirements related to conversions that will ensure both the current example code and the old example code will work. (The old example code is what most existing applications use.) If requiring the same representation is thought to be too limiting, then a requirement specific to dlsym() could be added instead. This would allow implementations where function pointers have a different representation to void *, and dlsym() meets the requirements by means of some compiler magic whereby the compiler "knows" about the special requirements of dlsym(). Alternatively, if consensus cannot be reached on additional requirements that would allow the current dlsym() example code to work, then we could reinstate the old dlsym() example code, leave 2.12.3 as it is, and reopen interpretation AI-003 with a view to solving it differently (for example, by requiring the c99 utility not to issue a diagnostic message when void * is converted to a function pointer using an explicit cast). Action: Either A. Change "Conforming implementations shall support conversion of pointers of any type to void * and back without loss of information." to "All function pointer types shall have the same representation as the type pointer to void. Conversion of a function pointer to void *, either using an explicit cast or through the implied conversion performed by the dlsym() function, shall not alter the representation. A void * value resulting from such a conversion can be converted back to the original function pointer type, using an explicit cast, without loss of information." or B. Add a specific requirement of some sort to the dlsym() page which ensures that all conforming implementations support the example code on that page. or C. In the EXAMPLES section on the dlsym() page change line 9078 from *(void **)(&fptr) = dlsym(handle, "my_function"); to fptr = (int (*)(int))dlsym(handle, "my_function"); and add a Note to Reviewers in the RATIONALE section stating that the rationale is expected to change as a result of interpretation AI-003 being reopened. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 16 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 51) [LANG, JR, KENNETH #53] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 4308 Section: none Problem: IEEE ballot ID 2387300023 Vote Approve reference to Section 2.4.1 has no page reference (in XSH Document) Action: Should read "Section 2.4.1 (on page 28)" _____________________________________________________________________________ COMMENT Enhancement Request Number 17 nick:xxxxxxxxxx Bug in XSHd2 alphasort (rdvk# 21) {NMS-examples-1} Tue, 26 Dec 2006 20:00:28 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 4764 Section: alphasort Problem: The example given uses free() ... this needs the header file to be included. Action: add after line 4764 # include _____________________________________________________________________________ COMMENT Enhancement Request Number 18 nick:xxxxxxxxxx Bug in XSHd2 bsearch (rdvk# 22) {NMS-examples-2} Tue, 26 Dec 2006 21:09:07 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 158 Line: 5632 Section: bsearch Problem: The bsearch example currently uses scanf to read strings into a 20 byte buffer ... while fine for this example, this is bad programming practice in general, and the example would be much improved if it used the new dynamic memory allocating scanf("%Ms") format specifier. This would allow this example to also double as an additional scanf example for this new code. NOTE - this ERN is dependent on the acceptance of XSH ERN 132 against the 2004 edition of the standard, which is currently still open. If that ERN is rejected, this must also be. Action: Delete line 5632. Delete line 5636. Replace line 5637 with while (scanf("%Ms", &node.string) != EOF) { Add after line 5646: free(node.string); _____________________________________________________________________________ COMMENT Enhancement Request Number 19 nick:xxxxxxxxxx Bug in XSHd2 dirname (rdvk# 24) {NMS-examples-3} Tue, 26 Dec 2006 21:47:41 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the entire example on lines 8750-8755 with: char *path = NULL, *pathcopy; size_t buflen = 0; ssize_t linelen = 0; int fd; linelen = getline(&path, &buflen, stdin); path[linelen-1] = 0; pathcopy = strdup(path); if (chdir(dirname(pathcopy)) < 0) { ... } if ((fd = open(basename(path), O_RDONLY)) >= 0) { ... close (fd); } ... free (pathcopy); free (path); _____________________________________________________________________________ Page: 261 Line: 8747 Section: dirname Problem: The example for dirname contains at least one serious problem: the fgets function will include the newline character. This example would be better if it used the getline function instead. Action: Replace the entire example on lines 8750-8755 with: char *path = NULL, *pathcopy; size_t buflen = 0; ssize_t linelen = 0; int fd; linelen = getline(&path, &buflen, stdin); path[linelen-1] = 0; pathcopy = strdup(path); if (chdir(dirname(pathcopy)) < 0) { ... } if ((fd = open(basename(path), O_RDONLY)) < 0) { ... } ... close (fd); free (path); free (pathcopy); _____________________________________________________________________________ COMMENT Enhancement Request Number 20 nick:xxxxxxxxxx Bug in XSHd2 dirname (rdvk# 23) {NMS-examples-4} Tue, 26 Dec 2006 21:52:54 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 262 Line: 8766 Section: dirname Problem: The second example for dirname is identical to the first (except with included headers). Action: Delete lines 8766-8782. _____________________________________________________________________________ COMMENT Enhancement Request Number 21 peter:xxxxxxxxx Bug in XSHd2 dlerror (rdvk# 1) {?} Tue, 31 Oct 2006 14:31:39 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: dlerror() is not required to be thread safe. The functionality could be provided by another function outside the standard. _____________________________________________________________________________ Page: 266 Line: 8898 Section: dlerror Problem: The description states that dlerror() shall return a null-terminated character string that describes the last error that occurred during dynamic linking processing. On at least Mac OS X, this is not the case, Mac OS X's dlerror returns the last error that occurred during dynamic linking on the current thread. If the last error occurred on a different thread then NULL will be returned. When I was implementing this for Mac OS X 10.3, I read the standard in such a way that I assumed this behavior was okay. The behavior was continued to current Mac OS X versions. The fact that dlerror() as defined by the specification may return an error that occurred on a different thread is documented in the description, however, it is not explicitly allowed for an implementation to only return errors that occur on the calling thread. Action: I'd like "occurred during dynamic linking processing." to read "occurred during dynamic linking processing, however, a thread safe implementation may return the last error that occurred on the current thread," _____________________________________________________________________________ COMMENT Enhancement Request Number 22 nick:xxxxxxxxxx Bug in XSHd2 dlopen (rdvk# 25) {NMS-examples-5} Tue, 26 Dec 2006 21:59:44 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 270 Line: 9032 Section: dlopen Problem: The are no examples listed for dlopen; however dlsym contains an example that also shows dlopen usage. Action: Change line 9032 from: None. to: See dlsym(). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 23 nick:xxxxxxxxxx Bug in XSHd2 dlsym (rdvk# 26) {NMS-dlsym-1} Tue, 26 Dec 2006 22:06:44 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 272 Line: 9103 Section: dlsym Problem: Typo in rationale Action: On line 9103, change However, POSIX-conforming implementations are required to support his, to However, POSIX-conforming implementations are required to support this, _____________________________________________________________________________ COMMENT Enhancement Request Number 24 nick:xxxxxxxxxx Bug in XSHd2 endpwent (rdvk# 27) {NMS-examples-6} Tue, 26 Dec 2006 22:23:27 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the example with: #include #include void printname(uid_t uid) { struct passwd *pwd; setpwent(); while((pwd = getpwent()) != NULL) { if (pwd->pw_uid == uid) { printf("name=%s\n",pwd->pw_name); break; } } endpwent(); } _____________________________________________________________________________ Page: 292 Line: 9636 Section: endpwent Problem: The example for getpwent/endpwent is so trivial as to be useless. Action: Replace the entire example, lines 9638-9649, with the following: The following example is a possible implementation of the getpwuid() function. It uses the getpwent() function to get successive entries in the user database, returning a pointer to a passwd structure that contains information about each user. The call to endpwent() closes the user database and cleans up. #include #include struct passwd * mygetpwuid(uid_t uid) { struct passwd *pwd; setpwent(); while((pwd = getpwent()) != NULL) { if (pwd->pw_uid == uid) return pwd; } endpwent(); return NULL; } _____________________________________________________________________________ EDITORIAL Enhancement Request Number 25 drepper:xxxxxxxxxx Bug in XSHd2 erf() (rdvk# 2) {ud-erf-int} Tue, 31 Oct 2006 16:53:01 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This appears to be now fixed by later versions of evince -- FC6 seems ok. _____________________________________________________________________________ Page: 300 Line: 9854 Section: erf() Problem: The PDF does not show the integral sign in the formula describing how to copmute the functions. The x just hangs above the 0. Action: Adjust sources to groff to print integral sign. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 50) [LANG, JR, KENNETH #54] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 305 Line: 10014 Section: none Problem: IEEE ballot ID 2387400023 Vote Approve reference to Section 2.3 has no page reference (in XSH Document) Action: Should read "Section 2.3 (on page 21)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 27 drepper:xxxxxxxxxx Bug in XSHd2 exec (rdvk# 3) {ud-exec-ss} Tue, 31 Oct 2006 16:55:14 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 309 Line: 10153 Section: exec Problem: The SCHED_SPORADIC support is not in base. Action: Shade "or SCHED_SPORADIC" and mark is SS. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 28 drepper:xxxxxxxxxx Bug in XSHd2 exec (rdvk# 4) {ud-exec-ulimit} Tue, 31 Oct 2006 16:57:23 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "ulimit()" to "getrlimit() and setrlimit()" _____________________________________________________________________________ Page: 311 Line: 10210 Section: exec Problem: The ulimit interface is obsolete. So the reference in exec should be marked as such, too. Action: Mark line 10210 also with OB in addition to XSI. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 29 nick:xxxxxxxxxx Bug in XSHd2 flock (rdvk# 30) {NMS-examples-7} Tue, 26 Dec 2006 22:34:46 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 344 Line: 11375 Section: flock Problem: The flock example is missing for printf prototype Action: Add #include after line 11375 _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 gwc:xxxxxxxxxxxxx Bug in XSHd2 fdopendir (rdvk# 15) [gwc fdopendir EBADF] Tue, 2 Jan 2007 16:42:32 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 356 Line: 11787 Section: fdopendir Problem: The description of the EBADF error for fdopendir() is currently: "The fd argument is not a valid file descriptor open for searching." Since the purpose of fdopendir() is to obtain a directory stream for use with readdir(), it should require the fd to be open for reading, not for searching. Action: Change "searching" to "reading". _____________________________________________________________________________ COMMENT Enhancement Request Number 31 nick:xxxxxxxxxx Bug in XSHd2 fdopendir (rdvk# 28) {NMS-examples-8} Tue, 26 Dec 2006 23:07:30 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 357 Line: 11812 Section: fdopendir Problem: The example for opendir() is fairly trivial, and includes two unrequired #includes. An example for fdopendir() would be useful. Action: Delete lines 11812 and 11814 (the includes of and ). Add the following after line 11824 Find And Open a File The following program fragment searches through a given directory looking for files larger than 1 MB. #include #include #include #include #include #include int main(int argc, char *argv[]) { struct stat statbuf; DIR *d; struct dirent *dp; int dfd, ffd; if ((d = fdopendir((dfd = open("./tmp", O_RDONLY)))) == NULL) { fprintf(stderr, "Cannot open ./tmp directory\n"); exit(1); } while ((dp = readdir(d)) != NULL) { if (dp->d_name[0] == '.') continue; /* there is a possible race condition here as the file could be renamed * between the readdir and the open */ if ((ffd = openat(dfd, dp->d_name, O_RDONLY)) == -1) { perror(dp->d_name); continue; } if (fstat(ffd, &statbuf) == 0 && statbuf.st_size > (1024*1024)) { /* found it ... */ printf("%s: %dk\n", dp->d_name, statbuf.st_size / 1024); } close(ffd); } closedir(d); close(dfd); return 0; } _____________________________________________________________________________ COMMENT Enhancement Request Number 32 nick:xxxxxxxxxx Bug in XSHd2 fflush (rdvk# 29) {NMS-examples-9} Wed, 27 Dec 2006 00:05:12 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As below plus Mark gets() OB _____________________________________________________________________________ Page: 377 Line: 12329 Section: fflush Problem: The fflush example uses the now obsolete/deprectated, and extremely unsafe, function gets(). No sample code should encourage a user to emply this function under any circumstances. Action: Replace the example on lines 12321-12336 with the following: char *user; char *oldpasswd; char *newpasswd; ssize_t llen; size_t blen; struct termios term; tcflag_t saveflag; printf("User name: "); fflush(stdout); blen = 0; llen = getline(&user, &blen, stdin); user[llen-1] = 0; tcgetattr(fileno(stdin), &term); saveflag = term.c_lflag; term.c_lflag &= ~ECHO; tcsetattr(fileno(stdin), TCSANOW, &term); printf("Old password: "); fflush(stdout); blen = 0; llen = getline(&oldpasswd, &blen, stdin); oldpasswd[llen-1] = 0; printf("\nNew password: "); fflush(stdout); blen = 0; llen = getline(&newpasswd, &blen, stdin); newpasswd[llen-1] = 0; term.c_lflag = saveflag; tcsetattr(fileno(stdin), TCSANOW, &term); free(user); free(oldpasswd); free(newpasswd); _____________________________________________________________________________ EDITORIAL Enhancement Request Number 33 ebb9:xxxxxxx Bug in XSHd2 fstatat (rdvk# 7) {ebb.fstatat.1} Tue, 31 Oct 2006 21:24:09 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 473 Line: 15690 Section: fstatat Problem: The DESCRIPTION of fstatat refers to a missing flag argument. Action: Replace line 15689: int fstatat(int fd, const char *restrict path, struct stat *restrict buf); With: int fstatat(int fd, const char *restrict path, struct stat *restrict buf, int flag); _____________________________________________________________________________ COMMENT Enhancement Request Number 34 ebb9:xxxxxxx Bug in XSHd2 fstatat (rdvk# 6) {ebb.fstatat.3} Tue, 31 Oct 2006 23:00:07 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: fstat() already provides the requested functionality and so we see no benefit to adding it. Implementations are free to do this as an extension. _____________________________________________________________________________ Page: 473 Line: 15727 Section: fstatat Problem: The original Solaris implementation of fstatat allows fstatat(fd, NULL, &st, 0) to be a synonym for fstat(fd, &st). Likewise, it allows fchownat(fd, NULL, owner, group, 0) to be a synonym for fchown(fd, owner, group). Although Solaris did not specify fchmodat, a similar argument would apply for fchmodat(fd, NULL, mode, 0) behaving like fchmod(fd, mode). The proposed wording is shown for fstatat, but if this aardvark is accepted, a similar alteration should be done for fchownat and fchmodat. One other thing to consider, but not proposed below, is that if this is approved, it might be worth consolidating fstat, stat, lstat, and fstatat into a single section, rather than the current split of fstat vs. the other three. Action: At line 15727, replace the text: The fstatat( ) function shall be equivalent... with: If path is not NULL, the fstatat( ) function shall be equivalent... After line 15739, insert a new paragraph: If path is NULL, the fstatat( ) function shall be equivalent to the fstat( ) function, and the AT_SYMLINK_NOFOLLOW bit in flag is ignored. At line 15758, add text: [EBADF] The path argument is NULL and the fd argument is not a valid file descriptor. (note to the editor - another aardvark covers whether EBADF and ENOTDIR should be swapped when path is relative; the intent here is that EBADF is mandatory if path is NULL and fd is not valid, regardless of how the other aardvark is resolved.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 35 ebb9:xxxxxxx Bug in XSHd2 fstatat (rdvk# 5) {ebb.fstatat.2} Tue, 31 Oct 2006 22:31:32 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: l15759 replace "searching" with "reading" and check all the EBADF errors for all the *at functions to ensure that they say reading and not searching (The remaining problems are covered by issue 15 in SD/1) OPEN pending an open action item 2007-02-06 _____________________________________________________________________________ Page: 473 Line: 15758 Section: fstatat Problem: In the fstatat ERRORS section, there is a conflict between EBADF (shall fail if path is not absolute and fd is neither AT_FDCWD nor open for search) and ENOTDIR (may fail if path is not absolute and fd is neither AT_FDCWD nor associated with a directory). Similar comments can be made for faccessat, fchmodat, fchownat, linkat, mkdirat, mkfifoat, mknodat, openat, readlinkat, renameat, symlinkat, unlinkat, and futimesat. Also, fdopendir requires failure if fd is not open for searching. In all of these cases, there is no definition of how an fd is to be opened for searching, and the FUTURE DIRECTIONS for open states that the use of O_EXEC on directories is unspecified. It seems awkward to have the mandatory failure dependent on unspecified capabilities. In practice, it would be nicer to get ENOTDIR if fd is not a directory, and leave EBADF (or maybe EACCES) as optional if fd is a directory but not searchable (either because the application provided an extension of O_EXEC on directories, or because the underlying file that the fd refers to does not currently have search permissions). The original Solaris behavior, on which the *at functions are modeled, documented ENOTDIR when fd was not a directory, and EBADF only when fd was not an open descriptor(http://docs.sun.com/app/docs/doc/816-5167/6mbb2jagb?a=view). Action: Replace line 15758 (under fstatat shall fail) with: [ENOTDIR] The path argument does not specify an absolute path and the fd argument is neither AT_FDCWD nor a valid file descriptor associated with a directory. Replace line 15769 (under fstatat may fail) with: [EBADF] The path argument is not an absolute path and fd is neither AT_FDCWD nor a file descriptor associated with a directory with search permissions. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 36 drepper:xxxxxxxxxx Bug in XSHd2 getdelim() (rdvk# 8) {ud-getdelim-1} Tue, 31 Oct 2006 17:28:27 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 526 Line: 17538 Section: getdelim() Problem: Let's show that we know the spec and avoid unnecessary conditionals. free(NULL) is a no-op. Action: Remove line 17538. _____________________________________________________________________________ OBJECTION Enhancement Request Number 37 gwc:xxxxxxxxxxxxx Bug in XSHd2 linkat (rdvk# 16) [gwc linkat and no-inode symlinks] Mon, 18 Dec 2006 11:54:29 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 731 Line: 23789 Section: link Problem: The description of linkat() includes the following statement: "Unless flag contains the AT_SYMLINK_FOLLOW flag, if path1 names a symbolic link, a new link is created for the symbolic link path1 and not its target." There is no allowance here for systems that do not support making hard links to symlinks, whereas for pax there is the statement: "If the selected archive format supports the specification of linked files, it shall be an error if these files cannot be linked when the archive is extracted, 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." The standard should either require similar behaviour to pax, or it should allow linkat() to return an error in this situation. The latter is perhaps more appropriate for a function call, and would be consistent with lchown() which gives an EOPNOTSUPP error when symbolic links do not have user and group IDs. The action proposed below adds the EOPNOTSUPP error. An alternative would be to allow either behaviour (i.e. linkat() can give EOPNOTSUPP or it can create a duplicate symlink). A related issue is file serial numbers for symlinks. There has been some discussion in the past about mandating them for XSI systems (because allowing readdir() to return an unspecified value in d_ino for symlinks is problematic). If such a change is made, then linkat() should also be changed to mandate support for hard links to symlinks on XSI systems. Action: At line 23789 change "Unless flag contains the AT_SYMLINK_FOLLOW flag, if path1 names a symbolic link, a new link is created for the symbolic link path1 and not its target." to "If the AT_SYMLINK_FOLLOW flag is clear in the flag argument and the path1 argument names a symbolic link, a new link is created for the symbolic link path1 and not its target, unless the implementation does not support making hard links to symbolic links in which case the linkat() call shall fail." After the linkat() EBADF error (line 23821) add "[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." _____________________________________________________________________________ COMMENT Enhancement Request Number 38 nick:xxxxxxxxxx Bug in XSHd2 link/linkat (rdvk# 12) {AI-2006-02-04} Thu, 16 Nov 2006 17:39:46 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a new paragraph after line 23768 on page 731: If path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself. Add a new paragraph to APPLICATION USAGE after line 23862 on page 733: If path1 refers to a symbolic link, application developers should use linkat() with appropriate flags to select whether or not the symbolic link should be resolved. _____________________________________________________________________________ Page: 733 Line: 23862 Section: link/linkat Problem: In the following email (sequence 8154), a problem with the link() API in the 2001 standard was highlighted. A lengthy discussion followed, and at the February 2006 Ottawa meeting I was given an action to prepare an aardvark when the time was right (draft 2). > Date: Wed, 16 Mar 2005 06:56:34 -0700 > From: Eric Blake > Subject: link(2) and symlinks > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Issues were recently raised on the GNU coreutils mailing list about the > behavior of ln(1) and link(1), based on the underlying link(2), in the > presence of symlinks (several messages into the thread starting here: > http://lists.gnu.org/archive/html/bug-coreutils/2005-03/msg00083.html). > It is probably worth an aardvark or two, but I would like some discussion > first. > > To begin with, the specification for link(2) (XSH page 692, line 22935) is > ambiguous - it is not clear whether a "pathname naming an existing file" > implies dereferencing a symlink before the link is created. For example, > Paul Eggert informed me that Solaris 9 allows the creation of a hardlink > to an existing symlink (even if the symlink is dangling or loops); while > OpenBSD 3.4 resolves the symlink and creates the hardlink to the > underlying file (or dies with ELOOP or ENOENT). Should both > implementation choices be allowed, and the wording improved to make this > clearer? > > - From here, consider the files: > $ touch A > $ ln -s A B > $ ln -s B C > > The implementation of link(1) (XCU page 547, line 21112) relies on the > ambiguity of link(2). So, on Solaris 9, "link C D" creates D as a > hardlink to C, where on OpenBSD 3.4, "link C D" creates D as a hardlink to > A, because that is the behavior of their respective link(2). Thus Solaris > link(1) provides functionality not possible with a compliant ln(1), but > OpenBSD link(1) is redundant with ln(1). Furthermore, if you then run "rm > A", Solaris has preserved the metadata (C is a symlink), but lost the data > (the contents of A are gone), while OpenBSD has preserved the data. Are > both implementations acceptable, and should the wording of link(1) be > touched up to mention this difference? > > On the other hand, the wording for ln(1) (XCU page 549 line 21198) seems > like it was trying to prevent hard links to symlinks, but remains > ambiguous. The standard is clear that "ln B E" must dereference B before > calling link(2), so that creating E as a hardlink to B is non-compliant. > Yet this is the behavior of GNU ln on systems that support hardlinks to > symlinks, and also of Solaris /bin/ln, so the wording in step 3 is > incompatible with historic implementations. Then there is the question of > whether "using the object that source_file references" implies a single > dereference, even if that still is a link, or if it means chasing the > symlink until the actual file (or a dangling link or loop) is found? > Running "ln C D" with Solaris /usr/bin/xpg4/ln makes D a hardlink to B > (only one level of dereferencing), while FreeBSD /bin/ln makes D a > hardlink to A (full symlink resolution was performed). If POSIX is going > to require ln to chase links, should it require chasing the link all the > way rather than relying on the ambiguity of link(2)? > > - -- > Life is short - so eat dessert first! > > Eric Blake yyyy:xxxxxxx It is the belief of the ORs that the 2001 standard was clear (with no ambiguity) in the required behavior of link("old", "new"); where "old" referenced a symbolic link: page 100-101, lines 3153-3159 only permit symbolic links to not be followed under very controlled circumstances, and the link() API is not a function listed as requiring to act on the link itself. Therefore, in the call above, "new" would be a link to the target of the symbolic link "old", and not to the symbolic link itself. However, despite this, several implementations do not conform in this respect. In the revision, the link() behavior should become implementation defined, and application usage should be added to assist developers who want a specific behavior. Action: Add a new paragraph after line 23768 on page 731: If path1 names a symbolic link, it is implementation-defined if link() follows the symbolic link, or creates a new link to the symbolic link itself. Add a new paragraph to APPLICATION USAGE after line 23862 on page 733: If path1 refers to a symbolic link, application developers should use linkat() with appropriate flags to select whether or not the symbolic link should be resolved or not. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 39 drepper:xxxxxxxxxx Bug in XSHd2 localeconv() (rdvk# 9) {ud-localeconv} Tue, 31 Oct 2006 21:47:13 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 751 Line: 24389 Section: localeconv() Problem: The choice of the locales used in the example is in hindsight unfortunate. Italy and the Netherlands use the Euro now. Furthermore, the currency_symbol value for Switzerland is wrong (must be "Fr."). Action: Replace lines 24389 and 24390 with: int_currency_symbol "EUR " "EUR " "NOK " "CHF " currency_symbol "‚" "‚" "kr" "Fr." In case this does not get through in UTF-8 form: the currency_symbol values for Italy and Netherlands is the Euro sign U+20AC. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 40 gwc:xxxxxxxxxxxxx Bug in XSHd2 mkstemp (rdvk# 17) [gwc mkstemp errors] Fri, 22 Dec 2006 10:18:20 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 807,808 Line: 26074,26090 Section: mkdtemp Problem: The change to the mkstemp() ERRORS section from SD5-XSH-ERN-168 has not been applied. This is presumably because of the merging of mkstemp() onto the mkdtemp() page. I'm not sure of the appropriate way to say "refer to open()" for the errors for one function while having a specific errors list for the other. I have made a (probably poor) attempt, but perhaps the editors can improve it. Action: On line 26074 change "These functions shall fail if:" to "For the mkstemp() function, refer to open(). The mkdtemp() function shall fail if:" On line 26090 change "These functions" to "The mkdtemp() function". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 41 gwc:xxxxxxxxxxxxx Bug in XSHd2 open (rdvk# 18) [gwc open O_DSYNC] Tue, 2 Jan 2007 16:43:48 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 895 Line: 28741-28743 Section: open Problem: The O_DSYNC tag got lost when O_DIRECTORY was added. Action: Reinstate the O_DSYNC tag between the unshaded and shaded parts of the text that currently appears as the O_DIRECTORY description. The unshaded text should form the description of O_DIRECTORY and the shaded text should form the description of O_DSYNC. _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 nick:xxxxxxxxxx Bug in XSHd2 open_memstream (rdvk# 67) {NMS-open-memstream-1} Thu, 4 Jan 2007 15:55:17 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add after line 29076 #include Change page XSH 902, lines 29060-29064 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 successfully written bytes for open_memstream( ) or the number of successfully written wide characters for open_wmemstream( ). The buffer shall be terminated by a null character for open_memstream( ) or a null wide character for open_wmemstream( ). 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 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. The buffer shall be terminated by a null character for open_memstream( ) or a null wide character for open_wmemstream( ), at the current file position indicator. Change the example to #include #include int main (void) { FILE *stream; char *buf; size_t len; off_t eob; stream = open_memstream (&buf, &len); if (stream == NULL) /* handle error */ ; fprintf (stream, "hello my world"); fflush (stream); printf ("buf=%s, len=%zu\n", buf, len); eob = ftello(stream); fseeko (stream, 0, SEEK_SET); fprintf (stream, "good-bye"); fseeko (stream, eob, SEEK_SET); fclose (stream); printf ("buf=%s, len=%zu\n", buf, len); free (buf); return 0; } _____________________________________________________________________________ Page: 903 Line: 29075 Section: open_memstream Problem: There are two problems with the open_memstream example (tested against glibc-2.4): first, the free() function is used, which requires to be included. Second, existing implementations when writing to a memory buffer always append a NUL byte, so the second fprintf (after the fseeko) will append a NUL byte, rendering the output on l;ine 29097 incorrect (it should only be "good-bye"). This is true even if the fprintf is replaced with an fwrite...there is always an extra \0 inserted into the buffer (truncating the string in this case). [[i.e. fwrite("good-bye", 1, 8, stream) actually places nine characters in the buffer, even though the return valuie is 8]]. I believe we should be documenting common existing practice, and this is contrary to the description in lines 29056-8. Action: 1. Fix the include problem: add after line 29076 #include 2. Fix the expected output: change line 29097 to buf=good-bye, len=8 3. Document the addition of the NUL byte: Change the description at lines 29055-29058 from: If a write moves the position to a value larger than the current length, the current length shall be set to this position. In this case a null character for open_memstream( ) or a null wide character for open_wmemstream( ) shall be appended to the current buffer. to: If a write moves the position to a value larger than the current length, the current length shall be set to this position. After any write, a null character for open_memstream( ) or a null wide character for open_wmemstream( ) shall be appended to the current buffer at the current position. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 43 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 49) [LANG, JR, KENNETH #55] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1011 Line: 32033 Section: none Problem: IEEE ballot ID 2387500023 Vote Approve reference to Table 2-4 has no page reference (in XSH Document) Action: Should read "Table 2-4 (on page 79)" _____________________________________________________________________________ OBJECTION Enhancement Request Number 44 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 64) [KAROCKI, PIOTR #11] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ISO C TC2 #68 needs to be applied fwprintf : http://www.opengroup.org/austin/docs/austin_280r1.txt look at g.G from fprintf() and apply similar (Nick has raised with ISO C but we can go ahead with the change) _____________________________________________________________________________ Page: 1030 Line: 16418 Section: none Problem: IEEE ballot ID 2374200023 Vote Approve Functions: fwprintf, swprintf, wprintf I think most description should be removed, and reader should be referenced to printf function - now "g,G" has description inconsistent with same conversion specifiers in "fprintf" (it has SD5-XSH-ERN-70 applied). Action: None given (see Problem) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 45 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 48) [LANG, JR, KENNETH #56] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1053 Line: 33241 Section: none Problem: IEEE ballot ID 2387600023 Vote Approve reference to Section 2.9.4 has no page reference (in XSH Document) Action: Should read "Section 2.9.4 (on page 52)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 46 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 47) [LANG, JR, KENNETH #57] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1056 Line: 33359 Section: none Problem: IEEE ballot ID 2387700023 Vote Approve reference to Section 2.9.4 has no page reference (in XSH Document) Action: Should read "Section 2.9.4 (on page 52)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 47 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 46) [LANG, JR, KENNETH #58] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1057 Line: 33380 Section: none Problem: IEEE ballot ID 2387800023 Vote Approve reference to Section 2.9.4 has no page reference (in XSH Document) Action: Should read "Section 2.9.4 (on page 52)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 48 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 45) [LANG, JR, KENNETH #59] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1058 Line: 33419 Section: none Problem: IEEE ballot ID 2387900023 Vote Approve reference to Section 2.9.4 has no page reference (in XSH Document) Action: Should read "Section 2.9.4 (on page 52)" _____________________________________________________________________________ OBJECTION Enhancement Request Number 49 gwc:xxxxxxxxxxxxx Bug in XSHd2 pthread_attr_getstack (rdvk# 11) [gwc p_a_setstack align] Thu, 9 Nov 2006 12:32:59 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: l 33459 change from: The stackaddr shall be aligned appropriately to be used as a stack; for example, pthread_attr_setstack( ) may fail with [EINVAL] if (stackaddr & 0x7) is not 0 to: The pthread_attr_setstack() function may fail with [EINVAL] if stackaddr does not meet implementation-defined alignment requirements. On line 33479 change: "(stackaddr + stacksize)" to: "((char *)stackaddr + stacksize)" In APPLICATION USAGE (line 33498) after: "The specification of the stackaddr attribute presents several ambiguities that make portable use of these functions impossible." add: "For example, the standard allows implementations to impose arbitrary alignment requirements on stackaddr. Applications cannot assume that a buffer obtained from malloc() is suitably aligned. Note that although the stacksize value passed to pthread_attr_setstack() must satisfy alignment requirements, the same is not true for pthread_attr_setstacksize() where the implementation must increase the specified size if necessary to achieve the proper alignment." _____________________________________________________________________________ Page: 1060 Line: 33459 Section: pthread_attr_getstack Problem: Additional text has been added to APPLICATION USAGE to acknowledge that the alignment requirements on stackaddr and (stackaddr + stacksize) make portable use of pthread_attr_setstack() impossible. In order to make non-portable use of pthread_attr_setstack(), application writers need to know the alignment requirements of the implementation(s) they are targeting. However, the standard does not require implementations to document the alignment requirements. It should state that the alignment requirements are implementation-defined. It would also be useful to mention in APPLICATION USAGE that pthread_attr_setstacksize() does not have any alignment requirement. There are two other minor problems that should be corrected at the same time. Firstly, the description of EINVAL includes the case of (stackaddr + stacksize) lacking proper alignment, but this is not mentioned in the main text. Secondly, (stackaddr + stacksize) is not a valid C expression since stackaddr has type void *. Action: Change: "The stackaddr shall be aligned appropriately to be used as a stack; for example, pthread_attr_setstack() may fail with [EINVAL] if (stackaddr & 0x7) is not 0." to: "The values stackaddr and ((char *)stackaddr + stacksize) shall be aligned appropriately to be used to specify a stack; for example, pthread_attr_setstack() may fail with [EINVAL] if (stackaddr & 0x7) is not 0. The alignment requirements for stackaddr and ((char *)stackaddr + stacksize) shall be implementation-defined." On line 33479 change: "(stackaddr + stacksize)" to: "((char *)stackaddr + stacksize)" In APPLICATION USAGE (line 33498) after: "The specification of the stackaddr attribute presents several ambiguities that make portable use of these functions impossible." add: "In particular, the standard allows implementations to impose arbitrary alignment requirements on stackaddr and ((char *)stackaddr + stacksize). Applications cannot assume that, for example, a buffer obtained from malloc() is suitably aligned. Note that although the stacksize value passed to pthread_attr_setstack() must satisfy alignment requirements, the same is not true for pthread_attr_setstacksize() where the implementation must increase the specified size if necessary to achieve the proper alignment." _____________________________________________________________________________ COMMENT Enhancement Request Number 50 drepper:xxxxxxxxxx Bug in XSHd2 Signal Concepts (rdvk# 31) {ud-readlinkat} Thu, 1 Feb 2007 07:01:01 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1259 Line: 39087 Section: readlinkat() Problem: The readlinkat() pointer page follows directly the page it points to. In the PDF it should be removed. Action: Remove page 1259 in XSH. _____________________________________________________________________________ OBJECTION Enhancement Request Number 51 gwc:xxxxxxxxxxxxx Bug in XSHd2 realpath (rdvk# 19) [gwc realpath futuredir] Mon, 18 Dec 2006 15:38:06 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1264-1265 Line: 39214-39257 Section: realpath Problem: The realpath() FUTURE DIRECTIONS section states: "In the future, passing a null pointer to realpath() for the resolved_name argument may be defined to have realpath() allocate space for the generated pathname." We should add this requirement in the revision. There is a known problem with realpath() that has been discussed before, which is that if PATH_MAX is not defined as a constant in then applications have no way of determining how large a buffer they need to allocate for it to be safe to pass to realpath(). Mandating the null pointer behaviour would solve this problem. With this change it may be worth moving realpath() from XSI to Base, however I have not proposed that in the changes below as the lack of a buffer length argument still leads me to regard this as a "second class" function. Perhaps one day a replacement with a better interface will become sufficiently common to be added to POSIX. As well as mandating the null pointer behaviour, we should add something about the use of a non-null pointer when PATH_MAX is not constant. I believe the most appropriate addition would be a statement that if PATH_MAX is not defined as a constant in then calling realpath() with a non-null resolved_name argument results in undefined behaviour. Action: At line 39214 change "The generated pathname shall be stored as a null-terminated string, up to a maximum of {PATH_MAX} bytes, in the buffer pointed to by resolved_name. If resolved_name is a null pointer, the behavior of realpath() is implementation-defined." to "If resolved_name is a null pointer, the generated pathname shall be stored as a null-terminated string in a buffer allocated by realpath(). Otherwise, if {PATH_MAX} is defined as a constant in the header, then the generated pathname shall be stored as a null-terminated string, up to a maximum of {PATH_MAX} bytes, in the buffer pointed to by resolved_name. If resolved_name is not a null pointer and {PATH_MAX} is not defined as a constant in the header, the behavior is undefined." At line 39218 replace the RETURN VALUE section with the following "Upon successful completion, realpath() shall return a pointer to the buffer containing the resolved name. Otherwise, realpath() shall return a null pointer and set errno to indicate the error. If the resolved_name argument is a null pointer, the pointer returned by realpath() can be passed to free(). If the resolved_name argument is not a null pointer and the realpath() call fails, the contents of the buffer pointed to by resolved_name are undefined." At line 39244 change "The generated pathname is stored in the actualpath array." to "The generated pathname is stored in the buffer pointed to by actualpath." At line 39247 change char *symlinkpath = "/tmp/symlink/file"; char actualpath [PATH_MAX+1]; char *ptr; ptr = realpath(symlinkpath, actualpath); to char *symlinkpath = "/tmp/symlink/file"; char *actualpath; actualpath = realpath(symlinkpath, NULL); if (actualpath != NULL) { ... use actualpath ... free(actualpath); } else { ... handle error ... } At line 39254 change "Since the maximum pathname length is arbitrary unless {PATH_MAX} is defined, an application generally cannot supply a resolved_name buffer with size {{PATH_MAX}+1}." to "Since realpath() has no length argument, if {PATH_MAX} is not defined as a constant in , applications have no way of determining how large a buffer they need to allocate for it to be safe to pass to realpath(). A {PATH_MAX} value obtained from a prior pathconf() call is out of date by the time realpath() is called. Hence the only reliable way to use realpath() when {PATH_MAX} is not defined in is to pass a null pointer for resolved_name so that realpath() will allocate a buffer of the necessary size." At line 39257 replace the text of the FUTURE DIRECTIONS section with "None". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 52 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 44) [LANG, JR, KENNETH #60] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1311 Line: 40734 Section: none Problem: IEEE ballot ID 2388000023 Vote Approve reference to "Scheduling Policies" has no page reference (in XSH Document) Action: Should read "Scheduling Policies (on page 44)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 53 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 43) [LANG, JR, KENNETH #61] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1313 Line: 40811 Section: none Problem: IEEE ballot ID 2388100023 Vote Approve reference to "Scheduling Policies" has no page reference (in XSH Document) Action: Should read "Scheduling Policies (on page 44)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 54 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 42) [LANG, JR, KENNETH #62] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1341 Line: 41538 Section: none Problem: IEEE ballot ID 2388200023 Vote Approve reference to Section 2.7.1 has no page reference (in XSH Document) Action: Should read "Section 2.7.1 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 55 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 41) [LANG, JR, KENNETH #63] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1342 Line: 41580 Section: none Problem: IEEE ballot ID 2388300023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 56 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 40) [LANG, JR, KENNETH #64] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1345 Line: 41705 Section: none Problem: IEEE ballot ID 2388400023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 57 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 39) [LANG, JR, KENNETH #65] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1349 Line: 41905 Section: none Problem: IEEE ballot ID 2388500023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 58 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 63) [KAROCKI, PIOTR #12] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1381 Line: 27409 Section: none Problem: IEEE ballot ID 2380600023 Vote Approve "Timners option" Action: "Timers option" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 59 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 38) [LANG, JR, KENNETH #66] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1409 Line: 43614 Section: none Problem: IEEE ballot ID 2388600023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 60 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 37) [LANG, JR, KENNETH #67] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1411 Line: 43683 Section: none Problem: IEEE ballot ID 2388700023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 61 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 36) [LANG, JR, KENNETH #68] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1412 Line: 43725 Section: none Problem: IEEE ballot ID 2388800023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 62 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 35) [LANG, JR, KENNETH #69] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1414 Line: 43793 Section: none Problem: IEEE ballot ID 2388900023 Vote Approve reference to Section 2.7 has no page reference (in XSH Document) Action: Should read "Section 2.7 (on page 39)" _____________________________________________________________________________ OBJECTION Enhancement Request Number 63 gwc:xxxxxxxxxxxxx Bug in XSHd2 socketpair (rdvk# 10) [gwc socketpair EMFILE] Wed, 1 Nov 2006 16:57:02 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1471 Line: 45582 Section: socketpair Problem: Since socketpair() opens two file descriptors it should have the same EMFILE description as pipe(). Action: Change "All file descriptors available to the process are currently open." to "All, or all but one, of the file descriptors available to the process are currently open." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 64 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 62) [KAROCKI, PIOTR #13] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1544 Line: 32005 Section: none Problem: IEEE ballot ID 2380700023 Vote Approve "functions may be withdrawn" - but in other places it is "functions may be removed". Action: Change to "removed". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 65 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 61) [KAROCKI, PIOTR #14] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1857 Line: 41040 Section: none Problem: IEEE ballot ID 2380800023 Vote Approve "dem_destroy" Action: Function name is "sem_destroy" :) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 66 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 66) [HOELZL, WERNER #3] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2196 Line: 0 Section: 3._utimes() Problem: IEEE ballot ID 2327000023 Vote Approve empty page Action: remove _____________________________________________________________________________ EDITORIAL Enhancement Request Number 67 ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 2 (rdvk# 65) [HOELZL, WERNER #4] Tue, 30 Jan 2007 16:16:04 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2305 Line: 0 Section: System_Interfaces_Contents Problem: IEEE ballot ID 2327100023 Vote Approve poorly legible text does not fit Action: change formatting