54 ballot objections, comments, and editorial comments were received. The following table summarizes the resolutions. Complete text of each objection, comment, or editorial comment and its detailed resolution follows the table. Number Balloter's ID Resolution -------- ------------- ---------- ERN #1 [Coord] Accept as marked ERN #2 [Coord] Accept ERN #3 [Coord] Accept ERN #4 [martin-1] Accept as marked ERN #5 [josey-3] Accept as marked ERN #6 [dwc-6] Accept ERN #7 [dwc-4] Accept ERN #8 [dwc-1] Accept ERN #9 [josey-1] Accept ERN #10 [dwc-2] Accept ERN #11 [dwc-3] Accept as marked ERN #12 [buerger-1] Duplicate of ERN #11 ERN #13 [dwc-7] Accept ERN #14 [dwc-5] Accept ERN #15 [josey-2] Accept ERN #16 [dwc-8] Accept ERN #17 [dwc-9] Accept ERN #18 [KAMP002] Accept as marked ERN #19 [josey-5] Accept ERN #20 [dwc-10] Accept ERN #21 [KAMP001] Accept as marked ERN #22 [dwc-11] Accept as marked ERN #23 [dwc-12] Accept as marked ERN #24 [buerger-2] Duplicate of ERN #23 ERN #25 [dwc-13] Accept ERN #26 [schwarm-1] Accept as marked ERN #27 [dwc-14] Accept as marked ERN #28 [josey-6] Accept ERN #29 [dwc-15] Accept ERN #30 [josey-4] Accept ERN #31 [dwc-16] Accept ERN #32 [dwc-17] Accept ERN #33 [dwc-18] Accept ERN #34 [dwc-19] Accept as marked ERN #35 [dwc-20] Accept ERN #36 [dwc-21] Accept as marked ERN #37 [buerger-3] Duplicate of ERN #36 ERN #38 [buerger-4] Accept ERN #39 [Wallach-1] Reject ERN #40 [dwc-22] Accept ERN #41 [dwc-23] Accept as marked ERN #42 [schwarm-2] Reject ERN #43 [dwc-24] Accept ERN #44 [dwc-26] Accept ERN #45 [dwc-25] Accept ERN #46 [dwc-27] Accept ERN #47 [dwc-28] Accept ERN #48 [dwc-30] Accept ERN #49 [dwc-29] Accept ERN #50 [dwc-31] Accept ERN #51 [dwc-32] Accept ERN #52 [dwc-33] Accept ERN #53 [dwc-34] Accept ERN #54 [dwc-35] Accept as marked _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 Coordination Bug in 1003.26 D2.1 (rdvk# 54) [Coord] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will delete the sentence. The draft doesn't have numerical real quantities. (Note to Technical Editor: Do the same for POSIX.13.) Status: done for both standards. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: SCC 14 (Quantities, Units and Letter Symbols) Coordination: SCC14 Comments on P1003.26/D2.1 Draft Standard for Information Technology-Portable Operating System Interface (POSIX)-Part 26: Device Control Application Program Interface (API) [C Language] March 10, 2003 Section 4.1: We object strongly to the statement in this clause, "Numerical quantities are presented in international style: comma is used as a decimal sign . . . ." Accepted international style in the English language is to use the point (period) as the decimal marker. The point is also specified as the decimal marker in IEEE/ASTM SI 10-2002, which establishes style in such matters for all IEEE standards. Action: Fix Bruce B. Barrow Chair, SCC14 b.barrow@ieee.org _____________________________________________________________________________ EDITORIAL Enhancement Request Number 2 Coordination Bug in 1003.26 D2.1 (rdvk# 53) [Coord] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: IEEE Staff Editorial Review Coordination: Here is a courtesy copy of a comment for P1003.26 just submitted: # Ballot/Comment Data for 0000380 (P1003.26) # Submitted Wed Mar 5 13:42:56 EST 2003 # Type: comment # Record Number: 00001001 ballot_code = 0000380 form_type = comment ieee_number = 00001001 name = Andy Ickowicz email = a.ickowicz@ieee.org phone = +1 732 562 3810 fax = +1 732 562 1571 org = IEEE Standards Activities page = General line = subclause = comment_type = Coordination comment = Draft meets editorial coordination requirements. suggested_remedy = Action: None. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 Coordination Bug in 1003.26 D2.1 (rdvk# 52) [Coord] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: SCC 10 (IEEE Dictionary) Coordination: Here is a courtesy copy of a comment for P1003.26 just submitted: # Ballot/Comment Data for 0000380 (P1003.26) # Submitted Wed Mar 5 13:41:22 EST 2003 # Type: comment # Record Number: 00001000 ballot_code = 0000380 form_type = comment ieee_number = 00001000 name = Andy Ickowicz email = a.ickowicz@ieee.org phone = +1 732 562 3810 fax = +1 732 562 1571 org = IEEE Standards Activities page = General line = subclause = comment_type = Coordination comment = This draft meets SCC10 coordination requirements. suggested_remedy = Action: None. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 Roger Martin Bug in 1003.26 D2.1 (rdvk# 50) [martin-1] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: If all of Don Cragun's actions are accepted, Accept, else Reject. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: I have reviewed and am familiar with the objections and comments included in the the negative ballot submitted by Don Cragun, Sun Microsystems. I support those objections and comments. Action: Take the required actions as proposed in Don's ballot. _____________________________________________________________________________ COMMENT Enhancement Request Number 5 Andrew Josey Bug in 1003.26 D2.1 (rdvk# 44) [josey-3] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: If all of Don Cragun's actions are accepted, Accept, else Reject. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: I support the ballot of Donald W. Cragun Action: Resolve the comments from Don Cragun _____________________________________________________________________________ COMMENT Enhancement Request Number 6 Don Cragun Bug in 1003.26 D2.1 (rdvk# 12) [dwc-6] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: x Line: 3 Section: Purpose Problem: (misuse of POSIX trademark) Trademarks are supposed to be used as adjectives, not as nouns. Action: Change "POSIX" on page x, line 3 to "the POSIX standards". _____________________________________________________________________________ COMMENT Enhancement Request Number 7 Don Cragun Bug in 1003.26 D2.1 (rdvk# 10) [dwc-4] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done, including a global search. _____________________________________________________________________________ Page: ix Line: 3 Section: Purpose Problem: (misuse of POSIX trademark) Trademarks are supposed to be used as adjectives, not as nouns. Action: Change "POSIX" on page ix, line 3 to "POSIX standards". This is a global problem in this draft. Check and correct all improper uses of the POSIX trademark. _____________________________________________________________________________ COMMENT Enhancement Request Number 8 Don Cragun Bug in 1003.26 D2.1 (rdvk# 7) [dwc-1] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: ii Line: 5 Section: ChangeHistory Problem: (Change History doesn't match draft.) The change history in this draft says that P1003.26 draft 2 produced in November 2002 is the first ballot draft. But, this is the first ballot draft and it is draft 2.1 produced in February 2003. Action: Correct the change history to specify that draft 2.1 is the first ballot draft and indicate what changed between drafts 2 and 2.1. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 9 Andrew Josey Bug in 1003.26 D2.1 (rdvk# 42) [josey-1] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (Note to Technical Editor: Also delete same paragraph in 1003.13 page xiii, lines 3-11.) Status: Done for both standards. _____________________________________________________________________________ Page: vi Line: 30-37 Section: Introduction Problem: These lines appear to state that no measurement of conformance or certification to this standard is permitted apart from individuals measuring. This seems to prevent even IEEE running a certification program. This seems beyond the scope of this standard to make this statement. Action: delete lines 30-37 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 Don Cragun Bug in 1003.26 D2.1 (rdvk# 8) [dwc-2] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: viii Line: 31 Section: Purpose Problem: (The C Language) The C Standard is normative reference 1. Normative reference 2 is POSIX.1- 2001. If you're going to use a typographical convention of putting normative references and bibliographic references in braces, that should be described in your typographical conventions section, not in a footnote. Action: Change "C Standard {2}1." on page viii, L31 to "C Standard {1}." (Note that this deletes the footnote 1 tag.) Delete page viii, lines 45-49. (Note that if you decide that you have to keep this footnote, "references in 1.2" has to at least be changed to "references in 2.1".) Add text to section 4.1 explaining the typographical convention using braces to surround normative references and bibliographic references. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 11 Don Cragun Bug in 1003.26 D2.1 (rdvk# 9) [dwc-3] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will delete the last sentence. Status: done _____________________________________________________________________________ Page: viii Line: 31 Section: Purpose Problem: (The C Language) There is no subclause B.1.3 and no subclause B.1.1.1 in this draft. Action: Delete the last sentence on page viii, line 31 or replace it with appropriate text pointing to relevant sections in this draft. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 12 Paul Buerger Bug in 1003.26 D2.1 (rdvk# 1) [buerger-1] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 11. Status: done _____________________________________________________________________________ Page: viii Line: 31 Section: unspecified Problem: The refernece to B.1.3 and B.1.1.1 sent me looking for these sections in this document. Presumably these references are to the appropriate sections in the C Standard. Problem: Clarify that these refences are to the appropriate sections in the C Standard. _____________________________________________________________________________ COMMENT Enhancement Request Number 13 Don Cragun Bug in 1003.26 D2.1 (rdvk# 13) [dwc-7] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: x Line: 37 Section: Purpose Problem: (amendments) IEEE PASC SEC resolutions that committed IEEE to participation in the development of the Austin Group Revision of POSIX.1-1990 and POSIX.2-1992 indicated that there are not supposed to be any more "rolling amendments" to the base standard. Action: Change ``are approved as "amendments" or'' on page x, line 37 to ``may be included in''. _____________________________________________________________________________ COMMENT Enhancement Request Number 14 Don Cragun Bug in 1003.26 D2.1 (rdvk# 11) [dwc-5] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: ix Line: 39-44 Section: Purpose Problem: (questionable guidance) There are several problems with this paragraph. They include, but are not limited to: 1. The POSIX trademark is misused. 2. The POSIX standards are specification of implementation requirements. UNIX systems are branded implementations of a UNIX specification (e.g. The Single UNIX Specification, Version 3 which is another name for POSIX.1-2001). A specification of an implementation is in no way similar to the implementation itself. This draft has no reason to suggest that all new applications must be written to be POSIX.26 conforming applications and that the ioctl() function specified by POSIX.1-2001 should be considered obsolescent. Action: Delete the paragraph on page ix, lines 39-44. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 15 Andrew Josey Bug in 1003.26 D2.1 (rdvk# 43) [josey-2] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: Done. I tried my best to distinguish between the parts of the text that apply to POSIX.1, and those that apply to POSIX.26. Made a consistency check with POSIX.1. _____________________________________________________________________________ Page: vi Line: 42 Section: Background Problem: Much of the background talks about POSIX.1 and also ISO/IEC 9945. The audience section especially talks about 9945. Since this is not POSIX.1 or ISO/IEC 9945 its confusing at best.It is similar but different form the preface in 9945:2002. I suggest it needs rewriting to focus on this standard in particular. Action: Rewrite large sections of v1-x so it is applicable to this standard, or at least make it clearer which parts of the text are general information and not relevant to this standard. If intended to be about 9945:2002 it needs to be consistent with that standard. _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 Don Cragun Bug in 1003.26 D2.1 (rdvk# 14) [dwc-8] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: Done. In addition, according to conversations between the balloter (Don Cragun) and the technical reviewer (Frank Prindle), all references to POSIX.13 conformance have been removed. The specifics of POSIX.13 conformace will be specified in each of the profiles. _____________________________________________________________________________ Page: 3-5 Line: 34-7 Section: 1.2.2 Problem: (Application Conformance) This entire section on application conformance is muddled by the discussion of the features it requires from other overlapping standards. POSIX.1 defines the same types of application conformance described in this section but is self consistent. Here the requirements are not at all clear. As an example, it seems that a Strictly Conforming POSIX.26 Application based on a POSIX.13 PSE51 profile is allowed to use any feature of POSIX.1 even if that feature is not specified by POSIX.13 profile PSE51. I realize that you can't require that a Strictly Conforming POSIX.26 Application be a Strictly Conforming POSIX.1 Application nor that it be a Strictly Conforming Application as defined by POSIX.13 because strictly conforming applications in those standards are not allowed to use POSIX.26 features. When you allow a strictly conforming POSIX.26 application to use facilities described in the "applicable language standards" without specifying what language standards are applicable you create more problems. On P4, L16-17 when you say that restrictions on a Conforming POSIX Application shall restrict a Strictly Conforming POSIX Application, I have to assume that you are talking about the definitions of those terms in POSIX.1's Base Definitions volume in subclause 2.2. But that doesn't make any sense to me. Action: Rewrite this section. In your rewrite I would suggest that you state that a Strictly Conforming POSIX.26 Application must be a Strictly Conforming POSIX Application as defined in POSIX.1 or a Strictly Conforming Application as defined in POSIX.13 except that it is allowed to use the interfaces specified in this Standard and is constrained by the text on P3, L40 through P4, L4 and restrictions placed on a Conforming POSIX.26 Application. I would also suggest that your definition of an ISO/IEC Conforming POSIX.26 Application be that it be an ISO/IEC Conforming POSIX Application as defined in POSIX.1 with this Standard listed as one of the ISO/IEC standards it uses. (Note that unless you plan to move this Standard up to an ISO/IEC Standard, you must omit this type of conformance from this Standard.) I also strongly suggest that you make similar changes for Conforming POSIX.26 Applications and Conforming POSIX.26 Applications Using Extensions. _____________________________________________________________________________ COMMENT Enhancement Request Number 17 Don Cragun Bug in 1003.26 D2.1 (rdvk# 15) [dwc-9] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. Deleted the reference to TC1 _____________________________________________________________________________ Page: 7 Line: 22 Section: 2.1 Problem: (technical corrigenda) By specifying ISO/IEC 9899:1999 TC1 is included, you imply that IEEE Std 1003.1-2001 TC1 is not included. Technically, when any technical corrigendum is approved it becomes part of the underlying standard and the original text in the standard it modifies no longer exists. Therefore, you don't need to mention technical corrigenda at all. Action: Do one of the following: 1. delete ", including Technical Corrigendum No. 1" from P7, L22 or 2. make both of the following changes: A. change "Technical Corrigendum No. 1" on P7, L22 to "all approved Technical Corrigenda". B. insert ", including all approved Technical Corrigenda" on P7, L26 before the final period. C. add ", including all approved Technical Corrigenda." to the end of P7, L28. D. add ", including all approved Technical Corrigenda." to the end of P7, L33. _____________________________________________________________________________ COMMENT Enhancement Request Number 18 Joerg Kampmann Bug in 1003.26 D2.1 (rdvk# 49) [KAMP002] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The footnote listing "substandards" will be deleted (See ERN 20.) By PASC resolution, it is not possible to integrate this standard into 1003.1-2001 until the next revision of that base standard by 2006. Status: done. _____________________________________________________________________________ Page: 7 Line: 23 Section: 2.1 Problem: The split of the whole POSIX standard into to many substandards may be confusing Action: Try to integrate this standard into POSIX 1003.1-200x (x>1). _____________________________________________________________________________ COMMENT Enhancement Request Number 19 Andrew Josey Bug in 1003.26 D2.1 (rdvk# 46) [josey-5] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done, including changing references throughout the document. _____________________________________________________________________________ Page: 7 Line: 24 Section: 2.1 Problem: We should reference ISO/IEC 9945:2002 parts 1 through 4 rather than IEEE Std 1003.1-2001 Action: Reference the ISO/IEC approved version of the IEEE Std 1003.1-2001 _____________________________________________________________________________ COMMENT Enhancement Request Number 20 Don Cragun Bug in 1003.26 D2.1 (rdvk# 16) [dwc-10] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 7 Line: 25-26,48-49 Section: 2.1 Problem: (partial listing of amendments) IEEE Std 1003.1-2001 is a revision of IEEE Std 1003.1-1990 and IEEE Std 1003.2-1992 with material included from several IEEE Std 1003.1x and IEEE Std 1003.2x amendments and draft amendments, and material merged in from other sources. Listing some of the amendments while not mentioning some of the other amendments calls into question whether {2} really refers to IEEE Std 1003.1-2001 or only selected pieces of it. Action: Delete "(Revision of...-1992)3." from P7, L25-26. Delete footnote 3 on P7, L48. _____________________________________________________________________________ COMMENT Enhancement Request Number 21 Joerg Kampmann Bug in 1003.26 D2.1 (rdvk# 48) [KAMP001] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will not wait until .13 is approved because that draft standard may reference .26; they need to be approved at approximately the same time. SSWG-RT will change this reference to the new .13 revision. See ERN 22 for strategy. Status: done. _____________________________________________________________________________ Page: 7 Line: 27 Section: 2.1 Problem: The reference to [3] IEEE Std. 1003.13-1998 ... Is referenced to existing standard as of 1998 Action: Wait until the 1003.13 standard is balloted and insert appropriate year of ballotin there :) _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 Don Cragun Bug in 1003.26 D2.1 (rdvk# 17) [dwc-11] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will use choice 2, but will not wait for .13 approval, but rather use the following strategy: Replace reference to 1998 version by reference to 200x version of .13 and add an editorial note(s) to the effect: "the approval date will be inserted editorially after .13 is approved (or if it is not approved, all references to .13 will be editorially deleted.)" Status: done. _____________________________________________________________________________ Page: 7 Line: 27-31 Section: 2.1 Problem: (Normative References) Since this standard is tied to IEEE Std 1003.1-2001, conformance to the 1998 version of the POSIX.13 profiles is not a suitable base for this standard. The synopses for the functions you specify in this use the restrict keyword from the 1999 C Standard. That keyword is not available in the 1990 C Standard and, therefore, is not available in an implementation supporting IEEE Std 1003.13-1998 profiles. Action: Choose one of the following: 1. remove all references to IEEE Std 1003.13 from this draft, or 2. do all of the following: A. wait for the revision of IEEE Std 1003.13-1998 to be adopted by IEEE, B. update the reference on P7, L27-28, to point to the approved revision, and C. remove the Note on P7, L30-31. I prefer choice 2. _____________________________________________________________________________ COMMENT Enhancement Request Number 23 Don Cragun Bug in 1003.26 D2.1 (rdvk# 18) [dwc-12] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In footnote 1, SSWG-RT will reverse the two sentences (as currently ordered, it is unclear to what standards "these standards" in the second sentence refers), and change "Annex C" to "Annex A". Status: done. _____________________________________________________________________________ Page: 7 Line: 41 Section: 2.1 Problem: (reference to non-existent text) There is no Annex C in this document. Action: Choose one of the following: 1. change "Annex C" on P7, L41 to point to appropriate text, 2. add the Annex C that this text points to, 3. delete the first sentence from P7, L41-42, or 4. delete footnote 1 on P7 completely. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 24 Paul Buerger Bug in 1003.26 D2.1 (rdvk# 2) [buerger-2] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 23. _____________________________________________________________________________ Page: 7 Line: 41 Section: 2.1 Problem: Reference to Annex C that does not exist. Action: Change the reference to Annex A that does conatin the refernced material. _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 Don Cragun Bug in 1003.26 D2.1 (rdvk# 19) [dwc-13] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: Done _____________________________________________________________________________ Page: 9 Line: 6-11 Section: 3 Problem: (undefined terms) I believe the intent of this draft was to use the same definitions and general concepts defined in POSIX.1's base definitions volume's clauses 3 and 4, but I haven't found any place in this draft that says POSIX.1's definitions (except character special file) apply in this draft. P9, L31-32 imply, but don't explicitly state, that POSIX.1's general concepts apply in this draft. POSIX.1 has "Definitions" and "General Concepts". I don't understand why this draft has "General Terms" and "General Concepts" in a clause titled "Terms and Definitions". Action: Change "Terms and Definitions" on P9, L6 to "Definitions and General Concepts". Change P9, L9 to: The Definitions and General Terms provided in POSIX.1 apply in this Standard unless modifications are specified in subclauses 3.1 and 3.2 below. Change "General Terms" on P9, L11 to "Definitions". _____________________________________________________________________________ COMMENT Enhancement Request Number 26 Steve Schwarm Bug in 1003.26 D2.1 (rdvk# 5) [schwarm-1] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Also, SSWG-RT will replace 'A "special device" is' with 'In this standard, a "special device" is'. The same term is used in .13 with a slightly different meaning. SSWG-RT will use an improved (and more precise) wording for the action, i.e.: Add the sentences: The driver for a "special device" may respond to the write() function to transfer data to the device or the read() function to collect information from the device. The interpretation of the information is still implementation defined. Status: done. _____________________________________________________________________________ Page: 9 Line: 43 Section: 3.2.1 Problem: A special device may still use read and/or write for data transfer but that is not clear from this description Action: Add the sentence: A "special device" may use the write() function to transfer data to the device or the read() function to collect information from the device. The interpretation of the information is still implimentation defined. _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 Don Cragun Bug in 1003.26 D2.1 (rdvk# 20) [dwc-14] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will delete the text as indicated in the first part of the Action. In addition, SSWG-RT will remove 3.1.1 (the definition of "character special file" and instead add "Character special files that have no structure defined by POSIX.1 can be accessed as defined in section 5." in place of the deleted text. SSWG-RT will remove from the conformance requirements (1.2.1.1, 1.2.1.2, and 1.2.2.1) all references to the Realtime Profiles (.13); instead, conformance of an implementation to this (.26) standard will imply conformance to POSIX.1. The draft of POSIX.13 Revision wil be changed so that conformance of an implementation to a Realtime Profile that requires posix_devctl() and the full filesystem semantics will require that implementation to provide mknod() as the only implementation-defined "way character special files are created"; An implementation conforming to a profile without full filesystem semantics will still be required to define the "way character special files are created", but this may be mknod() or may not (e.g. if the implementation does not support a filesystem). Status: done. _____________________________________________________________________________ Page: 9 Line: 44-47 Section: 3.2.1 Problem: (creating character special files) If you need a standard way to create a character special file, specify that the way to do so is to use the function in POSIX.1 that does so (mknod()). Action: Delete " and provide a way to create a character special file that provides a binding to the device driver when the open() function is called with the name of that character special file" from P9, L45-47. Add a requirement that the mknod() function specified by POSIX.1 must be implemented on POSIX.26 implementations even if the POSIX.1 XSI option isn't otherwise supported. Specify that appropriate values for the dev parameter are implementation-defined. Also specify that on POSIX.26 conforming implementations, mknod() can be used in a portable manner to create character special files as well as FIFOs. Or, preferably, get rid of subclause 3.2 completely and just rely on the definitions of "device" and "character special device" that are already present in POSIX.1. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 28 Andrew Josey Bug in 1003.26 D2.1 (rdvk# 47) [josey-6] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 9 Line: 48 Section: Preface Problem: The UNIX registered trademark acknowledgement needs to be corrected (remove licensed exclusively) Action: Correct as per the trademarks page in ISO/IEC 9945:2002. _____________________________________________________________________________ OBJECTION Enhancement Request Number 29 Don Cragun Bug in 1003.26 D2.1 (rdvk# 21) [dwc-15] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 10 Line: 7-19 Section: 3.3 Problem: (conflict with POSIX.1 requirements) POSIX.1 Base Definitions volume P217, L7687 and P219, L7749 do not allow a synonym for ENOTTY. There is no need for a synonym here; the description of ENOTTY in POSIX.1 is identical to the definition in this draft on P10, L11- 16 except for the last sentence. Action: Delete P10, L7-19. Change "[EBADCMD]" on P16, L36 to "[ENOTTY]". Change "[EBADCMD]" on P26, L34 to "[ENOTTY]". _____________________________________________________________________________ COMMENT Enhancement Request Number 30 Andrew Josey Bug in 1003.26 D2.1 (rdvk# 45) [josey-4] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 10 Line: 24 Section: 3.4.1 Problem: These are symbols for POSIX.26 not POSIX.1 Action: Change "POSIX.1 Symbols" to "POSIX.26 Symbols" _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 Don Cragun Bug in 1003.26 D2.1 (rdvk# 22) [dwc-16] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: Done. _____________________________________________________________________________ Page: 10-11 Line: 27,5-25 Section: 3.4.1 Problem: (feature test macro versus version macro) A feature test macro is not defined by an implementation, it is defined by an application before including standard headers to request that features and constraints specified by the corresponding standard are to be applied when standard headers are included. In POSIX.1, the feature test macro is _POSIX_C_VERSION. A version macro is defined by the implementation in a standard header to specify that the implementation conforms to the requirements specified by the corresponding standard. In POSIX.1, the version macro is _POSIX_VERSION (defined in ). This draft mixes the feature test macro and announcement macro in a way that makes it impossible for an implementation to simultaneously conform to POSIX.1 and the requirements specified in this draft. Action: Change "POSIX.1 Symbols" on P10, L24 to "POSIX.26 Symbols". Change P10, L27 through P11, L8 to: Version Test Macro The following symbolic constant shall be defined in : _POSIX26_VERSION Integer value indicating version of IEEE Std 1003.26 (C-language binding) to which the implementation conforms. For implementations conforming to this standard, the value shall be yyyymmL(with a note indicating that yyyymm will be replaced with the year and month of approval of this standard). The Compilation Environment A POSIX.26-conforming application should ensure that the feature test macro _POSIX26_C_SOURCE is defined before inclusion of any header. When an application includes a header described by this Standard, and when this feature test macro is defined to have the value yyyymmLa: Add a period to the end of P11, L18. Change " or by having defined _POSIX_DEVCTL_VERSION with a value larger than yyyymmL" on P11, L23-25 to ".". You also need to specify that _SC_POSIX26_VERSION is to be added to sysconf() as a value used to retrieve the value of _POSIX26_VERSION and that _SC_POSIX26_VERSION must be defined in . _____________________________________________________________________________ OBJECTION Enhancement Request Number 32 Don Cragun Bug in 1003.26 D2.1 (rdvk# 23) [dwc-17] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 11 Line: 36-40 Section: 3.4.2 Problem: (requirements about the visibility of symbols) Subclause 3.4.1 (P11, L9-25) talks about symbols required to appear; permitted, but not required to appear; and symbols not required or explicitly permitted. But, there is no specification in this draft specifying any of these classes except that a function prototype for posix_devctl() is required when is included. Among other things this means that a function prototype is required to use size_t, but is not allowed to provide a typedef for size_t. Action: At a minimum add text to the draft mirroring POSIX.1's System Interfaces volume's subclause 2.2.2 (The Name Space) specifying what symbols in addition to posix_devctl() are allowed to be defined by an implementation when is included by the application when the POSIX.26 enabling feature test macro is defined. At least use text from the POSIX.1's System Interfaces volume, P14-15, L552-569; and P17, L642 and supporting text. _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 Don Cragun Bug in 1003.26 D2.1 (rdvk# 24) [dwc-18] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 11 Line: 41-46 Section: 3.4.2 Problem: (C language options?) The only normative language reference you make in this draft is to C99. You do not define any C language options. (Furthermore, POSIX.1 now only specifies C Standard Language Dependent Support; Common Usage C disappeared in the revision.) Under what conditions do you believe an implementation of this draft would allow const qualifiers to be omitted? Action: Delete P11, L33-34. Delete P11, L41-46. _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 Don Cragun Bug in 1003.26 D2.1 (rdvk# 25) [dwc-19] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG will delete P12, lines 1-14. Note: SSWG-RT assume this wording, and that deleted by ERN 33, is left over from when PASC standards needed to support Common Usage C Language as well as standard C. Status: done _____________________________________________________________________________ Page: 12 Line: 1-14 Section: 3.4.2 Problem: (Draft doesn't specify types, etc.?) I'm confused. When the function prototype for posix_devctl() on P15, L26-30 specifies arguments of type int, void *, size_t, and int *; why doesn't that specify the types required by this draft (other than the fact that size_t is not specified in any way in this draft)? Why is an application allowed to provide its own function prototype rather than using the function prototype provided by the implementation in ? Why do you talk about conflicting requirements for functions defined by this draft and by C99 when the only function specified by this draft is clearly not defined by C99? Action: Either delete P12, L1-14 or explain why it is here. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 35 Don Cragun Bug in 1003.26 D2.1 (rdvk# 26) [dwc-20] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Since there are no environment variables, SSWG-RT will accept the action. Status: done _____________________________________________________________________________ Page: 13 Line: 26-29 Section: 4.1 Problem: (use of bold font) I didn't find any references to environment variables in this draft except here in the Conventions subclause. Action: If there aren't any environment variables specified in this draft: 1. delete the first sentence on P13, L16-29, and 2. change "It is also" in the second sentence on P13, L29 to "The bold font is". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 36 Don Cragun Bug in 1003.26 D2.1 (rdvk# 27) [dwc-21] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will delete P13, L46. Status: done. _____________________________________________________________________________ Page: 13 Line: 46 Section: 4.1 Problem: (reference to non-existent text) There is no subclause 2.4 in this draft and "See 2.4" is not a complete sentence. Action: Delete P13, L46 or replace it with a full sentence pointing to appropriate text that actually appears in the draft. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 37 Paul Buerger Bug in 1003.26 D2.1 (rdvk# 3) [buerger-3] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 36. Status: done. Deleted the reference. _____________________________________________________________________________ Page: 13 Line: 46 Section: 4.1 Problem: "See 2.4" should probably be "See 3.3" Action: Change to see 3.3 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 Paul Buerger Bug in 1003.26 D2.1 (rdvk# 4) [buerger-4] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 14 Line: 10 Section: 4.1 Problem: "NOTEs" is needlessly all caps Action: suggested_remedy = Change to "Notes" _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 Wallach Bug in 1003.26 D2.1 (rdvk# 51) [Wallach-1] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The parameter is dev_data_ptr. Through that parameter, one can point to the data necessary to specify the channel. A single "fildes" argument may thus be used to access a number of discretes, if the I/O driver is so designed. _____________________________________________________________________________ Page: 15 Line: 28 Section: 5.1.1.1 Problem: I think that there is a missing parameter for the posix_devctl function. I have encountered this problem while trying using ioctl for discrete input and output. The problem is that it is not convinient to open a file descriptor for each input (too many). It is more useful to open a file descriptor for a group of discrete inputs. In this case, we have to specify the exact discrete input. This information is missing from the command. I would think that the "fildes" parameter will point to the group of discretes, the "dcmd" will point to the command (read or write) and I am missing a parameter for the exact input spesification. Action: None given _____________________________________________________________________________ EDITORIAL Enhancement Request Number 40 Don Cragun Bug in 1003.26 D2.1 (rdvk# 28) [dwc-22] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 15,16 Line: 41,4,7 Section: 5.1.1.2 Problem: (NULL) NULL is not a defined term; NULL pointer is (at least in POSIX.1). Action: Change "non NULL" on P15, L41 to "not a NULL pointer". Change "non NULL" on P16, L4 to "not a NULL pointer". Change "NULL" on P16, L7 to "a NULL pointer". _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 Don Cragun Bug in 1003.26 D2.1 (rdvk# 29) [dwc-23] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT thinks there is a missunderstanding here. What the implementation leaves unspecified are the effects or using pointers within the data buffer passed to the driver (but the pointer to the data buffer itself works fine). SSWG-RT will clarify the wording to avoid this confusion. SSWG-RT will make the second sentence (lines 47-2) a new paragraph, since it is trying to define a different requirement from the first sentence (lines 45-47). Do not delete the sentence. Status: done. Added clarification words. _____________________________________________________________________________ Page: 15-16 Line: 45-2 Section: 5.1.1.2 Problem: (all attempts to pass data to/from a device driver produce unspecified results) The last sentence of this paragraph says that the effects are unspecified if nbyte is not zero. If this is really your intent, there is no reason to have this standard! Any reasonable implementation of this standard will have to require that drivers be able to transfer data between the calling thread's address space and the driver's address space. Action: Delete the last sentence from P15, L47 through P16, L2. _____________________________________________________________________________ COMMENT Enhancement Request Number 42 Steve Schwarm Bug in 1003.26 D2.1 (rdvk# 6) [schwarm-2] _____________________________________________________________________________ Accept_____ Accept as marked below______ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: In many hardware architectures, an integral number of whole pages of data would need to be transferred to the driver. This will in general be more than nbytes of data, but this in no way gives permission to the driver to move more than nbytes of data from memory to the device. _____________________________________________________________________________ Page: 15 Line: 45 Section: 5.1.1.2 Problem: the phrase "at least nbyte bytes" is incorrect. The device should not read past the location dev_data_ptr + (nbyte-1). This would implies that it is ok for the device to do so. Action: replace "at least nbyte bytes" with "no more than nbyte bytes" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 43 Don Cragun Bug in 1003.26 D2.1 (rdvk# 30) [dwc-24] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 16 Line: 24 Section: 5.1.1.3 Problem: (Returns versus Return Value) POSIX.1 uses "RETURN VALUE" as the header for this section. This draft uses "Returns" instead. Why are they different? Action: Change "Returns" on P16, L24 to "Return Value". _____________________________________________________________________________ OBJECTION Enhancement Request Number 44 Don Cragun Bug in 1003.26 D2.1 (rdvk# 32) [dwc-26] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 16 Line: 36-41 Section: 5.1.1.4 Problem: (EBADF, ENOTTY(EBADCMD), & EINVAL) The EBADF error condition in POSIX.1 (in general and in ioctl() in particular) means that the file descriptor specified by the fildes operand doesn't refer to an open file (open for output on write operations or open for input on read operations). The ENOTTY error condition is used to indicate that the fildes operand isn't associated with a file that accepts control commands (i.e. is not a character special file). The EINVAL error condition is used to report that the command is not known by the device driver. It is crucial that ioctl() and posix_devctl() functions use errno values consistent with each other! Action: Change P16, L36-37 to: [EBADF] The fildes argument is not a valid open file descriptor. Delete P16, L41. (See my objection #dwc-15 for the reason for changing EBADCMD to ENOTTY. I suggest moving this condition after L46 to maintain alphabetical order in the may fail errors.) Add after P16, L46: [EINVAL] The dcmd argument is not valid for this device. [ENOTTY] The fildes argument is not associated with a character special device that accepts control functions. _____________________________________________________________________________ OBJECTION Enhancement Request Number 45 Don Cragun Bug in 1003.26 D2.1 (rdvk# 31) [dwc-25] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 16-17 Line: 37-6 Section: 5.1.1.4 Problem: (error values) This draft specifies a bunch of error values, but never says where they are defined. There is no mention of any existing POSIX.1 defined headers in this draft (including ). Action: Specify somewhere in the draft that error numbers used in this Standard are defined in as specified by POSIX.1. _____________________________________________________________________________ COMMENT Enhancement Request Number 46 Don Cragun Bug in 1003.26 D2.1 (rdvk# 33) [dwc-27] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 17 Line: 1-4 Section: 5.1.1.4 Problem: (EFAULT) As described in POSIX.1's Rationale volume on P91-92, L3552-3556 and P92, L3568-3572, EFAULT is never listed in the errors sections of functions defined in POSIX.1. It shouldn't be listed in this standard either. The POSIX.1 standard still clearly specifies that if this condition is detected, EFAULT must be the error reported by the implementation (or in this case, the driver). (See POSIX.1's System Interfaces volume P23, L919- 923.) Action: Delete P17, L1-4. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 47 Don Cragun Bug in 1003.26 D2.1 (rdvk# 34) [dwc-28] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 17 Line: 16 Section: 5.1.1.5 Problem: (Cross-References versus See Also) POSIX.1 uses "SEE ALSO" as the header for this section. This draft uses "Cross-References" instead. Why are they different? Action: Change "Cross-References" on P16, L24 to "See Also". _____________________________________________________________________________ COMMENT Enhancement Request Number 48 Don Cragun Bug in 1003.26 D2.1 (rdvk# 36) [dwc-30] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Note: This was missing because ioctl() was not in POSIX.1-1996. Status: done _____________________________________________________________________________ Page: 17 Line: 19 Section: 5.1.1.5 Problem: (ioctl() connection) Given the obvious connection between ioctl() and posix_devctl(), why did you decide not to include ioctl() in the cross-references list? Action: Add "ioctl(), " to the see also list. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 49 Don Cragun Bug in 1003.26 D2.1 (rdvk# 35) [dwc-29] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (Note to Technical Editor: Should the document should reference the ISO standard here, instead of the IEEE standard, per Andrew Josey's other requests? It's probably best to follow the lead of 1003.1-2001 standard in this regard.) Status: done. Used the abbreviation POSIX.1, which now refers to the ISO standard _____________________________________________________________________________ Page: 17 Line: 19 Section: 5.1.1.5 Problem: (cross-book cross-references) There are no definitions for any of the functions listed here in this draft. Action: Change "close()," on P17, L19 to "The System Interfaces volume of IEEE Std 1003.1-2001 close(),". _____________________________________________________________________________ COMMENT Enhancement Request Number 50 Don Cragun Bug in 1003.26 D2.1 (rdvk# 37) [dwc-31] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Note: This was written because ioctl() was not in POSIX.1-1996. SSWG-RT acknowledges that ioctl() is in the current 1003.1-2001. The posix_devctl() function still provides an improved interface. Status: Done. _____________________________________________________________________________ Page: 21-26 Line: 13-42 Section: B Problem: (ioctl()) The entire rationale section in this draft doesn't seem to understand that ioctl() is a standard function specified in POSIX.1. Action: Read the description and rationale associated with POSIX.1 and rewrite this section to acknowledge that ioctl() is a POSIX.1 standard interface. If you didn't realize that ioctl() is already a POSIX standard interface, consider dropping posix_devctl() completely and specify appropriate extensions to ioctl() rather than adding this new function. _____________________________________________________________________________ COMMENT Enhancement Request Number 51 Don Cragun Bug in 1003.26 D2.1 (rdvk# 38) [dwc-32] _____________________________________________________________________________ Accept____ Accept as marked below__X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The UNIX trademark is acknowleged in the introduction section, so there is no need to do it here again. The footnote has been deleted. The trademark in the introduction has been written in the correct style, obtained from The Open Group's web page. _____________________________________________________________________________ Page: 21 Line: 48 Section: B Problem: (UNIX trademark footnote) Use proper trademark attribution. Action: Change "trademark of The Open Group" on P21, L48 to "registered trademark of The Open Group in the U.S. and other countries.". _____________________________________________________________________________ COMMENT Enhancement Request Number 52 Don Cragun Bug in 1003.26 D2.1 (rdvk# 39) [dwc-33] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 23-24 Line: 48-16 Section: B.3 Problem: (ioctl() versus posix_devctl()) When you write a new device driver, it has to be plugged into the operating system on which a POSIX.26 application is going to run. This rationale seems to be suggesting that all existing POSIX conforming implementations and all existing (non-TTY) character special device drivers be rewritten to replace the current ioctl() interfaces with posix_devctl() interfaces instead. We don't need a standard that tries to fragment the UNIX system and POSIX standard conforming implementation market into two markets (pre- POSIX.26 ioctl() versus post-POSIX.26 posix_devctl()). The implication of the paragraphs on P24, L9-16 is that existing ioctl() interfaces cannot be used to completely implement the interface specified in this draft! Action: Either reword this paragraph to make it clear that the intent is to allow applications to use posix_devctl() as an interface that provides better type checking, but can be fully implemented in the kernel using the existing ioctl() interfaces provided in current UNIX systems and other POSIX conforming systems, or withdraw the PAR for this project. _____________________________________________________________________________ COMMENT Enhancement Request Number 53 Don Cragun Bug in 1003.26 D2.1 (rdvk# 40) [dwc-34] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (Note to Technical Editor: Line 14-15, change the words "exits only" to "exists only"). Status: done. _____________________________________________________________________________ Page: 26 Line: 11-20 Section: B.8 Problem: (obsolescent behavior) If implementations start rewriting drivers to follow these guidelines and rewrite all drivers and the operating system to have a posix_devctl driver to kernel interface instead of an ioctl driver to kernel interface, all existing software using ioctl() on non-TTY character special files will stop working! You need to think much more about backwards compatibility before recommending that all new drivers be incompatible with all existing software using ioctl() on character special files. Note also that unless the size of the expected buffer is encoded in the command value, an implementation is going to have to modify the ioctl() and/or posix_devctl() function and/or system call every time a driver is installed. For implementation provided drivers this may not be a big deal. But, for third party drivers and user written drivers, this may be a huge stumbling block. I think you need to assume that the ioctl interface between the driver and libc is going to be around forever and that posix_devctl() will be a library routine that calls ioctl() under the covers. (See also my comment number dwc-33.) Action: Rewrite this section to indicate that posix_devctl() needs to be able to perform buffer size checks before calling ioctl() to do the real work. _____________________________________________________________________________ COMMENT Enhancement Request Number 54 Don Cragun Bug in 1003.26 D2.1 (rdvk# 41) [dwc-35] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will delete EBADCMD, but will retain EINVAL because here the failure detected is different from the failures that cause EINVAL on P16. This failure indicates that at the momemnt of I/O, the driver discovered that the data wouldn't fit into the buffer. Status: done. _____________________________________________________________________________ Page: 26 Line: 34-39 Section: B.9 Problem: (EBADCMD (or ENOTTY) & EINVAL) See also my objection dwc-15. You already have normative text on P16, L35 through P17, L7 that specify the required behavior for EBADCMD (or ENOTTY) and EINVAL as well as EBADF, EINTR, and EPERM. There is no need to specify some of them here again. Action: Delete P26, L34-39.