Document Number: AUSTIN/87 Title: XRATd6 Aardvark Change Request Report Revision Date: 2001-06-01 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XRAT Draft 6. Aardvark Summary Table ______________________ ERN 1 Reject ERN 2 Accept ERN 3 Accept ERN 4 Accept as marked ERN 5 Accept ERN 6 Accept ERN 7 Accept as marked ERN 8 Duplicate of 9 ERN 9 Accept ERN 10 Accept ERN 11 Accept ERN 12 Accept ERN 13 Accept ERN 14 Accept ERN 15 Accept ERN 16 Accept ERN 17 Accept ERN 18 Accept as marked ERN 19 Accept ERN 20 Accept ERN 21 Accept as marked ERN 22 Accept ERN 23 Accept as marked ERN 24 Accept ERN 25 Accept ERN 26 Accept ERN 27 Accept ERN 28 Accept as marked ERN 29 Accept ERN 30 Accept _____________________________________________________________________________ COMMENT Enhancement Request Number 1 curtis.smith@simtrol.com Bug in XRATd6 Scope (rdvk# 3) {cms-scope} Tue, 24 Apr 2001 13:49:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 3294 Line: 54-57 Section: Scope Problem: (Draft 5 ERN reference: XBDd5 ERN 76 ) Listing the requirement of an n-bit neutral architecture here without additional comment seems to suggest that reasonable effort to fulfil this requirement was made; whereas, in reality, the group contrarily mandated an architecture with an 8-bit byte. Action: Add comment in square brackets or italics to clearly indicate editorial matter rather than part of the requirements saying: "This requirement was rejected." Possibly add a cross reference to the rationale for 'byte' in section A.3 Definitions. [Ed recommendation: Reject The "n-bit neutral" referred to in the scope, is about the changes that were made in Single UNIX Specification Version 2 to remove 32-bit dependencies that were in the original specifications when support for systems larger than 32-bit was added. Its about n-bit cleanliness and *implicit* assumptions rather than the explicit ones, http://www.UNIX-systems.org/whitepapers/64bit.html has some background. The 8-bit byte is (now) an explicit requirement rather than an assumption. ] _____________________________________________________________________________ COMMENT Enhancement Request Number 2 ajosey@opengroup.org Bug in XRATd6 A.3 (rdvk# 27) {aj.symlink} Fri, 18 May 2001 15:14:46 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3316 Line: 943 Section: A.3 Problem: (Draft 5 ERN reference: NA ) The text needs updating since the introduction of the XSI function lchown() requires an owner/group to a symbolic link on an XSI conformant system Action: Change the sentence commencing on line 947 "As a" to: As a result of alignment with the Single UNIX Specification, the lchown() function is included as part of the XSI extension and XSI conformant systems support an owner and a group associated with a symbolic link. There was no consensus to define further attributes for symbolic links, and for systems not supporting the XSI extension only the file type bits in the st_mode member and the st_size member of the stat structure are required to be applicable to symbolic links. Change the sentence commencing "Because there is no..." on line 956 to: Because there is no requirement for systems not supporting the XSI extension that there be an association of ownership with symbolic links, there is no interface in the Base standard to change ownership. _____________________________________________________________________________ COMMENT Enhancement Request Number 3 gwinn@res.ray.com Bug in XRATd6 A.4.14 (rdvk# 28) {JMG6-3} Sat, 19 May 2001 02:27:31 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3329 Line: 1509 Section: A.4.14 Problem: (Draft 5 ERN reference: NA ) The statement "The relationship between tm_yday and the day of week, day of month, and month is presumed to be specified elsewhere and is not given in POSIX.1." is a bit in the reader's face, and could be softened. Action: Change to say: "The relationship between tm_yday and the day of week, day of month, and month is in accordance with the Gregorian Calendar, and so is not specified in POSIX.1." _____________________________________________________________________________ COMMENT Enhancement Request Number 4 ajosey@opengroup.org Bug in XRATd6 A.7.3.1 (rdvk# 15) {aj.is_wctype} Fri, 11 May 2001 16:18:01 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: yes, change is_wctype to iswctype _____________________________________________________________________________ Page: 3337 Line: 1825 Section: A.7.3.1 Problem: (Draft 5 ERN reference: NA ) Should the reference be iswctype() rather than is_wctype() Action: change is_wctype to iswctype ? _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 Jon Hitchcock Bug in XRATd5 LC_TIME (rdvk# 4) {jjh51} Fri, 27 Apr 2001 19:14:58 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3341 Line: 2006 Section: LC_TIME Problem: Having corrected the AD start date in the example Christian era (XRATd5 ERN 7), it is essential to also change the "offset" from 0 to 1 so that the years are numbered correctly. (My mistake for forgetting this last time.) Action: Change a zero to a one in line 2006 so it starts: era "+:1:0001/01/01: _____________________________________________________________________________ EDITORIAL Enhancement Request Number 6 dwc@spartan.eng.sun.com Bug in XRATd6 (rdvk# 30) [DWC-7] Mon, 21 May 2001 23:29:03 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3346 Line: 2244-2258 Section: A.8.3 Problem: (TZ rationale) The rationale associated with all of the environment variables in this section, except TZ, have headings denoting the environment variable name and are presented in alphabetic order. Action: Add a heading for the TZ enironment variable rationale after P3347, L2292 similar to those on P3346, L2259; P3347, L2270; P3347, L2279; and P3347, L2286. Move P3346, L2244-2258 to follow the newly added heading. If the resolution of my XBD ERN against the TZ environment variable (DWC-1) resulted in text being added to the rationale, move that added rationale here as well. _____________________________________________________________________________ COMMENT Enhancement Request Number 7 ajosey@opengroup.org Bug in XRATd6 A.12.2 (rdvk# 13) {aj.stat} Fri, 11 May 2001 15:25:06 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change stat to stat() change unlink to unlink() _____________________________________________________________________________ Page: 3363 Line: 2942 Section: A.12.2 Problem: (Draft 5 ERN reference: NA ) stat should be stat() ? Action: change stat to stat() [function not utility] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 8 Jon Hitchcock Bug in XRATd6 Change History (rdvk# 24) Fri, 18 May 2001 10:57:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_9 Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 3367,3507 Line: 2992-4,8965-7 Section: Change {jjh61} Problem: The rationale claims that the change history sections only describe the technical changes since Issue 5, but in fact they describe changes since Issue 4, Version 2. I guess it has already been decided what is intended to be listed in these sections, but I would argue for more (rather than less) change history. When porting an application written by another developer, it is common to get errors saying that a name is undefined in the implementation being used. When this happens, it is useful to be able to find out quickly whether there is no defintion because the name is obsolete or because it is a new invention. Then further information can be found, and a decision made on how to change the source. The documentation of the implementation being used is unlikely to help, but the change history and future directions sections of the standard are useful in this situation, even if they give little detail about what the name meant, or will mean. Action: Change the six occurances of "5" to "4, Version 2". [Ed recommendation: Dup of 9] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 9 ajosey@opengroup.org Bug in XRATd6 B1.4 (rdvk# 25) {aj.B.1.4} Fri, 18 May 2001 12:09:27 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3367 Line: 2993 Section: B1.4 Problem: (Draft 5 ERN reference: NA ) The use of the word "since" appears to confuse some readers Action: Change "since Issue 5" to "from Issue 5" on line 2993 only (note that the rest of this section is just talking about the changes since issue 5 and is correct). [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 ajosey@opengroup.org Bug in XRATd6 B.1.4 (rdvk# 21) {aj.stroull} Sun, 13 May 2001 08:40:29 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3370 Line: 3113 Section: B.1.4 Problem: (Draft 5 ERN reference: NA ) (correction on previous aardvark submission, aardvark discard previous) typo, stroull() should be strtoull() Action: change as per problem statement -> strtoull() [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 11 ajosey@opengroup.org Bug in XRATd6 B.1.4 (rdvk# 20) {aj.pthread_schedsetprio} Sun, 13 May 2001 08:32:50 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3370 Line: 3118 Section: B.1.4 Problem: (Draft 5 ERN reference: NA ) typo, pthread_schedsetprio() should be pthread_setschedprio() Action: change as per problem statement [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 12 eggert@twinsun.com Bug in XRATd6 B.2.3 (rdvk# 6) {eggert-2001050701} Mon, 7 May 2001 23:04:30 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3380 Line: 3521 Section: B.2.3 Problem: (Draft 5 ERN reference: NA ) The sentence says "POSIX.1 prohibits conforming implementations from restarting interrupted system calls." Even in POSIX.1-1996 this was not quite true, since the application could use an extension to obtain restarted calls. And with POSIX.1-200x it is not true even for conforming applications, due to SA_RESTART. Action: Append "of conforming applications unless the SA_RESTART flag is in effect for the signal" to the sentence. _____________________________________________________________________________ COMMENT Enhancement Request Number 13 eggert@twinsun.com Bug in XRATd6 B.2.4.4 (rdvk# 7) {eggert-2001050702} Tue, 8 May 2001 00:15:09 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3392 Line: 4055 Section: B.2.4.4 Problem: (Draft 5 ERN reference: NA ) This section says that the most common behavior of an interrupted function is to give an [EINTR] error. This was true for POSIX.1-1996, but is no longer true for POSIX.1-200x when SA_RESTART is used. The discussion in this section should also cover the case for SA_RESTART. Action: Append "unless the SA_RESTART flag is in effect for the signal" to the end of the first sentence (lines 4054-4055). Append the following at the end of section B.2.4.4 (after line 4069): "If a signal-catching function returns while the SA_RESTART flag is in effect, an interrupted function is restarted at the point it was interrupted. Portable applications cannot make assumptions about the internal behavior of interrupted functions, even if the functions are async-signal-safe. For example, suppose the read() function is interrupted with SA_RESTART in effect, the signal-catching function closes the file descriptor being read from and returns, and the read() function is then restarted; in this case the application cannot assume that the read() function will give an [EBADF] error, since read() might have checked the file descriptor for validity before being interrupted." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 14 ajosey@opengroup.org Bug in XRATd6 B.2.8.3 (rdvk# 12) {aj.memlockall} Fri, 11 May 2001 13:48:31 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3405 Line: 4642 Section: B.2.8.3 Problem: (Draft 5 ERN reference: NA ) The text references nonexistent memlockall(), should be mlockall() Action: change "memlockall()" to "mlockall()" [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 15 ajosey@opengroup.org Bug in XRATd6 B.2.8.3 (rdvk# 18) {aj.qnx} Sat, 12 May 2001 07:18:29 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3413 Line: 4997 Section: B.2.8.3 Problem: (Draft 5 ERN reference: NA ) It seems inappropriate/inconsistent to have the parenthetical description of QNX here Action: delete (a Canadian OS vendor specializing in realtime embedded systems on 80x86-based processors) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 16 Jens.Schweikhardt@marconi.com BUG in XRATd6 (rdvk# 1) [Schweikhardt] Thu, 19 Apr 2001 08:55:25 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3459 Line: 7078 Section: none Problem: Typo suspected: acutators Action: Change "acutators" to "actuators" [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 17 ajosey@opengroup.org Bug in XRATd6 B.2.9.5 (rdvk# 10) {aj.barrier_wait} Fri, 11 May 2001 13:36:28 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3463 Line: 7250 Section: B.2.9.5 Problem: (Draft 5 ERN reference: NA ) The text references barrier_wait() should be pthread_barrier_wait() Action: change "barrier_wait()" to "pthread_barrier_wait" [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 18 ajosey@opengroup.org Bug in XRATd6 B.2.11.7 (rdvk# 19) {aj.posix_trace_userevent} Sat, 12 May 2001 07:23:01 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change to posix_trace_event _____________________________________________________________________________ Page: 3490 Line: 8320 Section: B.2.11.7 Problem: (Draft 5 ERN reference: NA ) There is no function called posix_trace_userevent() Action: Not sure, delete the reference here? _____________________________________________________________________________ EDITORIAL Enhancement Request Number 19 ajosey@opengroup.org Bug in XRATd6 B.2.12 (rdvk# 11) {aj.lseeko} Fri, 11 May 2001 13:42:34 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3493 Line: 8463 Section: B.2.12 Problem: (Draft 5 ERN reference: NA ) The text references nonexistent lseeko(), should be ftello() Action: change "lseeko()" to "ftello()" [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 20 ajosey@opengroup.org Bug in XRATd6 C1.4 (rdvk# 26) {aj.C.1.4} Fri, 18 May 2001 12:11:05 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3507 Line: 8966 Section: C1.4 Problem: (Draft 5 ERN reference: NA ) The use of the word "since" appears to confuse some readers Action: Change "since Issue 5" to "from Issue 5" on line 8966 only [Ed recommendation: Accept] ____________________________________________________________________________________________ COMMENT Enhancement Request Number 21 eggert@twinsun.com Bug in XRATd6 C.1.7.2 Concepts Derived from the ISO C Standard (rdvk# 5) {eggert-2001050302} Thu, 3 May 2001 23:14:13 +0100 (BST) ____________________________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add after 9037 The behavior on overflow is undefined for ISO C arithmetic. Therefore, the standard utilities can use "bignum" representation for integers so that there is no fixed maximum unless otherwise stated in the utility description. Similarly, standard utilities can use infinite-precision representations for floating point arithmetic, so long as these representations exceed the ISO C requirements. This section addresses only the issue of semantics; it is not intended to specify syntax. For example, ISO C requires that '0L' be recognized as an integer constant equal to zero, but utilities like awk and sh are not required to recognize '0L' (though they are allowed to, as an extension). ISO C requires that a C compiler must issue a diagnostic for constants that are too large to represent. Most standard utilities are not required to issue these diagnostics; for example, the command diff -C 2147483648 file1 file2 has undefined behavior, and the "diff" utility is not required to issue a diagnostic even if the number 2 147 483 648 cannot be represented. ____________________________________________________________________________________________ Page: 3509 Line: 9037 Section: C.1.7.2 Problem: (Draft 5 ERN reference: NA ) The ISO C standard does not allow bignum representation for signed long. It requires that there must be a maximum signed long value, and a C program can compute that value. A naive reader of XSUd6 section 1.7.2.1 might think that it forbids utilities from using bignum representation for large integers. However, I don't think the standard was meant to forbid these higher-quality implementations. Similarly, I don't think the standard was meant to forbid higher-quality representations for floating-point. Also, a naive reader might think that all ISO C syntaxes for constants must be supported, e.g. the integer 'L' suffix or hexadecimal floating-point constants. Furthermore, a naive reader might think that, since ISO C requires a diagnostic for constants out of range, a similar requirement is placed on standard utilities. These misconceptions should be cleared up. Action: The behavior on overflow is undefined for ISO C arithmetic. Therefore, the standard utilities can use "bignum" representation for integers so that there is no fixed maximum. Similarly, standard utilities can use infinite-precision representations for floating point arithmetic, so long as these representations exceed the ISO C requirements. This section addresses only the issue of semantics; it is not intended to specify syntax. For example, ISO C requires that '0L' be recognized as an integer constant equal to zero, but applications like 'awk' and 'sh' are not required to recognize '0L' (though they are allowed to, as an extension). ISO C requires that a C compiler must issue a diagnostic for constants that are too large to represent. Standard utilities are not required to issue these diagnostics; for example, the command "diff -C 2147483648 file1 file2" has undefined behavior, and the "diff" utility is not required to issue a diagnostic even if the number 2147483648 cannot be represented. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 22 ajosey@opengroup.org Bug in XRATd6 C.1.13 (rdvk# 23) {aj.builtin} Wed, 16 May 2001 08:41:55 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3517 Line: 9376 Section: C.1.13 Problem: (Draft 5 ERN reference: NA ) Editorial rework Based on the ISO POSIX-1 standard p1 process model, Action: change "Based on the ISO POSIX-1 standard p1 process model," to "Based on the POSIX standard process model," [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 23 Donn Terry Bug in xbdd5 Bug in xrat (rdvk# 22) [DST-18] Tue, 15 May 2001 12:37:34 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: -> "while true" , "while :" _____________________________________________________________________________ Page: 3517 Line: 9392 Section: C.1.13 Problem: I don't know what a "while\true" or "while\:" construct is. I presume some sort of typographical coding was attempting to say (in CW) "while true" and "while :". Action: Fix. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 24 curtis.smith@simtrol.comBug in XRATd6 C.2.6.4 Arithmetic Expansion (rdvk# 2) {cms-suffices} Thu, 19 Apr 2001 13:38:28 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3528 Line: 9835 Section: C.2.6.4 Problem: (Draft 5 ERN reference: NA ) Incorrect plural form. Action: Change "suffices" to "suffixes". _____________________________________________________________________________ COMMENT Enhancement Request Number 25 ajosey@opengroup.org Bug in XRATd6 C.3.1 (rdvk# 14) {aj.qmgr} Fri, 11 May 2001 16:13:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3545 Line: 10519 Section: C.3.1 Problem: (Draft 5 ERN reference: NA ) The text references a qmgr utility, which is not in the spec Action: change "and qsub utilities" to "utility" [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 ajosey@opengroup.org Bug in XRATd6 D.2.2 (rdvk# 9) {aj.spawn} Fri, 11 May 2001 13:08:40 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3559 Line: 10925 Section: D.2.2 Problem: (Draft 5 ERN reference: NA ) The text references spawn(), should be posix_spawn() and posix_spawnp() Action: change "and spawn()" to "posix_spawn(), and posix_spawnp()" [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 27 ajosey@opengroup.org Bug in XRATd6 D.2.3 (rdvk# 8) {aj.getch} Fri, 11 May 2001 13:06:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3560 Line: 10967 Section: D.2.3 Problem: (Draft 5 ERN reference: NA ) The text references a non existent getch() function, this should be getchar() Action: change getch() to getchar() [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 gwinn@res.ray.com Bug in XRATd6 Appendix E Subprofiling (rdvk# 29) {JMG6-5} Sat, 19 May 2001 02:39:01 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Mail seq austin-group-l 3354 indicates that this objection is resolved by other changes in XBD. _____________________________________________________________________________ Page: 3579 Line: 11601 Section: Appendix Problem: (Draft 5 ERN reference: NA ) Making the Subprofiling Option Groups non-normative has the effect of precluding the planned revision of IEEE Std 1003.13-1998, thus orphaning the POSIX-compliant RTOS industry, including many flavors of RT Linux. Arguments that the list isn't perfect could as well be used against all of 1003.1-200x. Action: Move the Subprofiling Option Groups appendix to a normative volume, and mark the appendix itself as normative. _____________________________________________________________________________ COMMENT Enhancement Request Number 29 ajosey@opengroup.org Bug in XRATd6 E.1 (rdvk# 16) {aj.signgam} Sat, 12 May 2001 06:53:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3582 Line: 11747 Section: E.1 Problem: (Draft 5 ERN reference: NA ) signgam() is not a function, but an external integer Action: Change just to "signgam" ? [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 30 ajosey@opengroup.org Bug in XRATd6 E.1 (rdvk# 17) {aj.wcswcs} Sat, 12 May 2001 07:12:02 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3583 Line: 11798 Section: E.1 Problem: (Draft 5 ERN reference: NA ) wcswcs() is a legacy function. we should consider whether it wise to recommend inclusion of legacy functions in the subprofiling section Action: remove wcswcs() from XSI_WIDE_CHAR: [update from Frank] Remove: ftime() from XSI_SINGLE_PROCESS getwd() from XSI_FILE_SYSTEM mktemp() from XSI_FILE_SYSTEM utimes() from XSI_FILE_SYSTEM wcswcs() from XSI_WIDE_CHAR marked up]