116 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 [coordination] Accept ERN #2 [coordination] Accept ERN #3 [coordination] Accept ERN #4 [martin-1] Accept as marked ERN #5 [josey-9] Accept as marked ERN #6 [josey-4] Accept ERN #7 [dwc-5] Accept as marked ERN #8 [KAMP007] Accept as marked ERN #9 [dwc-1] Accept ERN #10 [KAMP001] Reject ERN #11 [josey-8] Accept ERN #12 [KAMP004] Accept as marked ERN #13 [dwc-2] Accept ERN #14 [KAMP009] Reject ERN #15 [josey-3] Accept ERN #16 [KAMP003] Reject ERN #17 [KAMP010] Reject ERN #18 [KAMP0005] Reject ERN #19 [dwc-3] Accept ERN #20 [KAMP002] Accept as marked ERN #21 [buerger-1] Duplicate of ERN #19 ERN #22 [dwc-4] Accept ERN #23 [KAMP006] Duplicate of ERN #19 ERN #24 [KAMP008] Accept ERN #25 [KAMP011] Accept as marked ERN #26 [LynuxWorks #11] Accept as marked ERN #27 [LynuxWorks #12] Reject ERN #28 [LynuxWorks #13] Reject ERN #29 [KAMP012] Accept as marked ERN #30 [KAMP013] Reject ERN #31 [LynuxWorks #1] Accept as marked ERN #32 [LynuxWorks #14] Reject ERN #33 [buerger-2] Accept ERN #34 [LynuxWorks #2] Reject ERN #35 [josey-1] Duplicate of ERN #36 ERN #36 [dwc-6] Accept ERN #37 [buerger-3] Accept ERN #38 [LynuxWorks #15] Reject ERN #39 [LynuxWorks #3] Accept as marked ERN #40 [LynuxWorks #16] Reject ERN #41 [schleicher-1] Reject ERN #42 [LynuxWorks #17] Accept ERN #43 [buerger-5] Duplicate of ERN #42 ERN #44 [schleicher-3] Duplicate of ERN #42 ERN #45 [dwc-7] Accept as marked ERN #46 [schleicher-2] Reject ERN #47 [buerger-4] Accept as marked ERN #48 [dwc-8] Accept ERN #49 [dwc-9] Accept as marked ERN #50 [dwc-10] Accept ERN #51 [schleicher-5] Reject ERN #52 [schleicher-4] Reject ERN #53 [KAMP014] Reject ERN #54 [KAMP015] Reject ERN #55 [dwc-11] Accept ERN #56 [dwc-12] Accept ERN #57 [dwc-13] Accept ERN #58 [dwc-14] Accept ERN #59 [dwc-15] Accept as marked ERN #60 [dwc-16] Accept as marked ERN #61 [dwc-17] Accept ERN #62 [josey-7] Accept as marked ERN #63 [dwc-18] Accept as marked ERN #64 [KAMP016] Accept ERN #65 [dwc-19] Accept as marked ERN #66 [dwc-20] Accept ERN #67 [dwc-21] Accept ERN #68 [dwc-22] Accept ERN #69 [josey-6] Accept as marked ERN #70 [schleicher-6] Accept ERN #71 [LynuxWorks #4] Duplicate of ERN #70 ERN #72 [buerger-6] Duplicate of ERN #70 ERN #73 [dwc-23] Accept ERN #74 [josey-5] Accept as marked ERN #75 [buerger-7] Accept ERN #76 [buerger-10] Accept ERN #77 [KAMP017] Accept ERN #78 [KAMP018] Reject ERN #79 [dwc-24] Accept ERN #80 [dwc-25] Accept ERN #81 [buerger-8] Accept ERN #82 [KAMP019] Reject ERN #83 [KAMP020] Reject ERN #84 [dwc-26] Accept ERN #85 [dwc-27] Accept ERN #86 [dwc-28] Accept ERN #87 [dwc-29] Accept ERN #88 [dwc-30] Accept ERN #89 [dwc-31] Accept ERN #90 [dwc-32] Accept ERN #91 [dwc-33] Accept ERN #92 [dwc-34] Accept ERN #93 [dwc-35] Accept ERN #94 [dwc-36] Accept ERN #95 [dwc-37] Accept ERN #96 [dwc-38] Accept ERN #97 [dwc-39] Accept ERN #98 [dwc-40] Accept ERN #99 [LynuxWorks #18] Reject ERN #100 [dwc-41] Accept ERN #101 [dwc-42] Accept ERN #102 [LynuxWorks #5] Duplicate of ERN #101 ERN #103 [dwc-43] Accept ERN #104 [dwc-44] Accept ERN #105 [LynuxWorks #6] Accept ERN #106 [buerger-9] Duplicate of ERN #105 ERN #107 [dwc-45] Accept as marked ERN #108 [LynuxWorks #7] Accept ERN #109 [KAMP021] Accept ERN #110 [LynuxWorks #8] Reject ERN #111 [LynuxWorks #9] Accept ERN #112 [josey-2] Accept as marked ERN #113 [dwc-46] Accept ERN #114 [dwc-47] Accept ERN #115 [LynuxWorks #10] Accept as marked ERN #116 [dwc-48] Accept _____________________________________________________________________________ COMMENT Enhancement Request Number 1 Coordination Bug in 1003.13 D2.1 (rdvk# 116) [coordination] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: SCC 14 (Quantities, Units and Letter Symbols) Coordination: Date: Tue, 04 Mar 2003 16:33:14 -0500 FR: Joe Gwinn TO: Bruce Barrow Subject: Re: CC of ballot for P1003.13 Revision from b.barrow@ieee.org Bruce, At 05:45 PM 2003-03-03 -0500, Bruce Barrow wrote: >Joe, > >Not to worry. I "coordinated", which means that, on behalf of SCC14 (which >worries about metric practice and stuff), I looked it over. I don't vote, >but I can make comments. In this case I had no comments. We of course had coordination in the old paper-based days, and the coordination ballot either said it was OK as is, or made some comments which had the practical effect of negative ballots. I guess the IEEE needs to add a choice "coordinated; no comments" or the like, so the intent is clear in the electronic copy. Joe Action: None _____________________________________________________________________________ COMMENT Enhancement Request Number 2 Coordination Bug in 1003.13 D2.1 (rdvk# 115) [coordination] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: IEEE Staff Editorial Review Coordination: MEMO TO: Balloting Center FROM: Savoula Amanatidis DATE: 6 March 2003 RE: Editorial Coordination of P1003.13/D2.1 I have reviewed P1003.13/D2.1 and it meets all the requirements for Editorial Coordination. Sincerely, Savoula Amanatidis Managing Editor, IEEE Standards Activities Voice: +1 732 562 3831 Fax: +1 732 562 1571 Email: s.amanatidis@ieee.org Action: None. _____________________________________________________________________________ COMMENT Enhancement Request Number 3 Coordination Bug in 1003.13 D2.1 (rdvk# 114) [coordination] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: SCC 10 (IEEE Dictionary) Coordination: MEMO TO: Balloting Center FROM: Savoula Amanatidis DATE: 6 March 2003 RE: SCC10 Coordination of P1003.13/D2.1 I have reviewed Clause 3 Definitions of P1003.13/D2.1 and it meets all the requirements for SCC10 Coordination. Sincerely, Savoula Amanatidis Managing Editor, IEEE Standards Activities Voice: +1 732 562 3831 Fax: +1 732 562 1571 Email: s.amanatidis@ieee.org Action: None _____________________________________________________________________________ COMMENT Enhancement Request Number 4 Roger Martin Bug in 1003.13 D2.1 (rdvk# 107) [martin-1] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: If all of Don Cragun's actions 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.13 D2.1 (rdvk# 88) [josey-9] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: If all of Don Cragun's actions accepted, Accept; else Reject. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I am familiar with the ballot of Donald W. Cragun and support his comments. Action: Resolve the comments from Donald W. Cragun. _____________________________________________________________________________ COMMENT Enhancement Request Number 6 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 83) [josey-4] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: Done. Made the following changes: - Droped the requirement for POSIX_CHILD_MAX=25, because it is already in the new POSIX.1 - Droped the requirement for POSIX_NGROUPS_MAX=8, because it is already in the new POSIX.1 - Droped the PRIORITY_RANGES option, because it is no longer necessary (several changes along the document) - Added the mmap() and munmap() functions to the POSIX_TYPED_MEMORY_OBJECTS option in annex 2 (in two table entries) - Added the sched_get_priority_max, sched_get_priority_min, sched_rr_get_interval functions to the POSIX_THREAD_PRIORITY_SCHEDULING option in annex 2 (in two table entries) - Replaced IEEE Std 1003.1-2001 with ISO/IEC 9945:2003 in the normative references section. The later is identical to IEEE Std 1003.1-2001 with TC1. Changed in various places in the document. _____________________________________________________________________________ Page: 0 Line: 0 Section: All Problem: Need to sync with IEEE Std 1003.1-2001 Corr 1 Action: Need to sync with Technical Corrigendum Number 1 to IEEE Std 1003.1-2001 _____________________________________________________________________________ COMMENT Enhancement Request Number 7 Don Cragun Bug in 1003.13 D2.1 (rdvk# 15) [dwc-5] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: IEEE said it was ok to acknowledge people who worked on the previous standard, and SSWG-RT decided to do so. That is why there are two lists. SSWG-RT will clarify which are the old participants and which are the new participants (although the lists are already so annotated, the difference is subtle and easily overlooked) in a style similar to that of 9945-1:1996. Status: Added unnumbered headers for "participants" and "participants in 1998 version". Moved the new participants in front of the old ones _____________________________________________________________________________ Page: xxiii Line: 0 Section: Participants Problem: (old participants list) This draft doesn't have a section titled "Participants" like there is in POSIX.1-2001. The participants list you show on Pxxi-xxiii was for POSIX.13-1998. You have a draft participants list for POSIX.13-200x. You don't need both lists. Action: Delete pages xxi through xxiii. Add a new "Participants" section heading at the top of Pxxiv. _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 65) [KAMP007] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is not normative text (and thus may not be "objected" to). The balloter does not supply the text that will satisfy his objection. Reject changes to lines 14 and 25 because they do not appear relevant here in this introductory background material. Because SSWG-RT have decided to profile 1003.26 in this document, add posix_devctl() to line 33 as suggested. Status: Done _____________________________________________________________________________ Page: xv Line: 5-41 Section: Basic_Realtime_Multitasking_and_Synchronisation Problem: The whole list is not very stringent. e.g. line 14 "Inter-thread communication mechanism..." is missing a statement of "blocking" and "non.-blocking" or line 25 "System time in units of clock ticks" or line 33 "Minimal synchronous ..." Action: for line 14: add a remark of blocking and non-blocking IPC for line 25: add a remark of the fact that clock ticks are normally adjustable, so that granularity of timing events can be enhanced for line 33: here is necessary a hint to IEEE 1003.26 (posix_devctl()) _____________________________________________________________________________ COMMENT Enhancement Request Number 9 Don Cragun Bug in 1003.13 D2.1 (rdvk# 11) [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.13 draft 2 produced in July 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 10 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 59) [KAMP001] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: These paragraphs address entirely different issues, and are thus separate paragraphs for a reason. SSWG-RT will delete the word "four" from the first paragraph (page xi, line 39) to alleviate future confusion. Status: done _____________________________________________________________________________ Page: xii Line: 11 Section: Introduction Problem: The content of this paragraph is in some parts similar to the content of paragraph page xi line 39-46 (p.xii - Line 11: Four profiles have been defined .../p.xi Line 39:...specifies four realtime profiles ...) Action: Try to combine these two paragraphs into one. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 11 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 87) [josey-8] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: xi Line: 20 Section: Introduction Problem: Use the ISO/IEC reference in preference to the IEEE Std ? Action: Now we have the ISO/IEC 9945:2002 standard it would seem preferable to mention it either in place or as well as IEEE Std 1003.1-2001. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 12 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 62) [KAMP004] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG will insert "(AEPs)" here, but note that this is non-normative introductory material. The term "Application Environment Profile" and its acronym are already in the Definitions (3.2.1), and the Abbreviations (4.2.7). Status: done _____________________________________________________________________________ Page: xiv Line: 20 Section: Rationale_on_Background Problem: Paragraph reads:...describes a set of application environment profiles ... Action: Here is a good place to introduce the acronym "AEP" - as well as in a glossary _____________________________________________________________________________ COMMENT Enhancement Request Number 13 Don Cragun Bug in 1003.13 D2.1 (rdvk# 12) [dwc-2] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: xi Line: 21-23 Section: Introduction Problem: (partial list 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 you really mean IEEE Std 1003.1-2001 or only selected pieces of it. Action: Change " (which includes... 1003.1q-2000)" on Pxi, L21-23 to ".". _____________________________________________________________________________ COMMENT Enhancement Request Number 14 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 67) [KAMP009] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is covered in paragraph beginning at line 28, though no specific file systems are mentioned. Balloter's action includes no specific "newer" file systems, so this would seem adequate. Remember this is non-normative background material. _____________________________________________________________________________ Page: xvi Line: 21 Section: local_filesystem Problem: this paragraph seems to be a bit outdated for a modern standard (I mean the reference to RT-11 or RSX-11M) - there are more modern filesystems, perhaps leave the legacy stuff in there including also OpenVMS but add newer ones. Action: already mentioned in Problem. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 15 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 82) [josey-3] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: Done _____________________________________________________________________________ Page: xiii Line: 24 Section: Introduction Problem: Misuse of the UNIX trademark in the term "typically non-UNIX tm". See http://www.unix.org/trademark.html for a pointer to the trademark usage guide. Action: consult guide for guidance on approved formats for usage of the registered trademark or remove words in parentheses. Change TM to the registered trademark symbol (R) if the trademark continues to be used. _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 61) [KAMP003] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is not normative text (and thus may not be "objected" to). Therefore we are treating this as an editorial comment. The text in the draft is the intended text. Minimum hardware required or "a bit less" is precisely what we want. This standard cannot have any formal hardware requirements. _____________________________________________________________________________ Page: xiii Line: 35 Section: Szenario Problem: ... minimum hardware typically required is specified. This has a semantic of either minimum hardware required or "a bit less". Action: Leave out "typically". The sentence will then read: ... minimum hardware required is specified. _____________________________________________________________________________ COMMENT Enhancement Request Number 17 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 68) [KAMP010] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: There is no current POSIX standard or study group on this subject. This is a list of related standards activities. _____________________________________________________________________________ Page: xix Line: 37 Section: Related_Standards_Activities Problem: some of the newer RTOSes have a philosophy of HA (high availability) - I am missing a remark addressing HA Action: Include a list-element of HA _____________________________________________________________________________ OBJECTION Enhancement Request Number 18 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 63) [KAMP0005] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is not normative text (and thus may not be "objected" to). Therefore we are treating this as an editorial comment. FAQ is neither a product nor a standard. The term "realtime" is defined in POSIX.1-2001, and 1003.13 cannot redefine it. _____________________________________________________________________________ Page: xiv Line: 39 Section: Rationale_on_Background Problem: I am missing a reference to the FAQ of comp.realtime, where you can find a very good definition of "real-time" and "real-time operating systems (RTOS)" Action: Try to introduce the basic ideas of these FAQ into the standard at this place E.g. Like: a RTOS has the following 6 (six) properties: - Multiple flow of control (multithreading/multitasking) - different priorities assigned to different processes/threads - preemptive scheduling - priority inheritance/priority ceiling - synchronisation of processes / threads - knowledge of maximum duration of system calls, interrupt latency, and how long the processor is in state of "interrupt disabled" _____________________________________________________________________________ COMMENT Enhancement Request Number 19 Don Cragun Bug in 1003.13 D2.1 (rdvk# 13) [dwc-3] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. Searched for the references on the Web _____________________________________________________________________________ Page: xiv Line: 42-49 Section: Rationale_on_Background Problem: (strange trademarks) Except for the VxWorks trademark attribution, all of the attributions on this page are strange or incomplete. Action: Change "pSOS is now" on Pxiv, L43 to "pSOS is". Change "VRTX32 is now" on Pxiv, L44 to "VRTX32 is". Change Pxiv, L46 to be a complete attribution for RT-Linux. Change Pxiv, L47 to be a complete attribution for QNX. Change Pxiv, L48 to be a complete attribution for RTEMS. _____________________________________________________________________________ COMMENT Enhancement Request Number 20 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 60) [KAMP002] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Actually, there are 3 appendices, and they have nothing to do with ISPICS, whatever that may have been in some earlier draft. SSWG-RT will fix these to correctly identify the appendices. No need define ISPICS, because it will no longer appear in the draft. SSWG-RT will fix the rest of the "Organization of this Standard" section to reflect current organization. Status: Done. _____________________________________________________________________________ Page: xii Line: 45 Section: Organization_of_this_standard Problem: ISPICS is a not well known term - read would not understand what is meant Action: Put it into a glossary or define it right at that spot _____________________________________________________________________________ EDITORIAL Enhancement Request Number 21 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 10) [buerger-1] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 19. _____________________________________________________________________________ Page: xiv Line: 46-48 Section: unspecified Problem: There seems to be some information missing in footnotes 4 through 6 Action: Supply the missing words. _____________________________________________________________________________ COMMENT Enhancement Request Number 22 Don Cragun Bug in 1003.13 D2.1 (rdvk# 14) [dwc-4] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. Searched the web for the references. RT11 and RTX11M are now trademarks of Mentec Inc. _____________________________________________________________________________ Page: xvi Line: 47-48 Section: Local_File_System Problem: (strange trademarks) The RT-11 and RSX-11M attributions on this page are strange. Action: Change "RT-11 is now" on Pxvi, L47 to "RT-11 is". Change "RSX-11M is now" on Pxvi, L48 to "RSX-11M is". _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 64) [KAMP006] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 19. (Note to Technical Editor: Here is the a possibly complete attribution for QNX) Status: done. _____________________________________________________________________________ Page: xiv Line: 47 Section: footnotes Problem: Missing continuation of lines for RT-Linux, QNX, RTEMS Action: As of QNX the line should be read as follows: 5. QNX is a registered trademark of QNX Software Systems Ltd. (QSSL) _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 66) [KAMP008] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT believes the company is now HP. Technical editor will insert the correct name. Status: I found in the web that it belongs to Mentec Inc. _____________________________________________________________________________ Page: xvi Line: 47 Section: footnotes Problem: ... 2. RT-11 .... of Compaq 3. RSX-11M ... of Compaq the merger of Compaq with HP should be mentioned here Action: correct the two lines to the proper company name (which I do not know exactly!) _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 69) [KAMP011] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT agree the text is difficult to parse - "technical" is not the right fix though. SSWG-RT will use "PSE51 systems are typically embedded in larger systems...". This will align this text with our own definition of embedded. Status: done. _____________________________________________________________________________ Page: 2 Line: 42 Section: 1.3.1_Minimal Problem: These systems are typically embedded in systems dedicated to .... I see the recursiveness of this definition however there may be a source of misunderstanding. We normally call the first kind of systems ("these systems") (IT- or data processing) systems and the second kind of systems ("embedded in systems dedicated ...") technical systems; e.g. a washing machine with a little processor inside doing all the control stuff: the processor with its control-software is the (IT- or data processing) system and the washing machine is the technical system. And the processor is dedicated to unattended control of the I/O devices controlling the technical system (I hope this is meant by the author of that paragraph...) Action: for a non-native English speaking individual I would suggest something like: "These systems are typically embedded in _technical_ systems. They are dedicated to control ..." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 99) [LynuxWorks #11] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT agree that the table should include both kinds of interfaces (functions and external variables), and that several of the latter have been omitted or misnamed in the table. SSWG-RT will Change title of second column in table to be "Included Interfaces". SSWG-RT will add: environ to POSIX_SINGLE_PROCESS errno to POSIX_SINGLE_PROCESS h_errno to POSIX_NETWORKING optarg to POSIX_STRING_MATCHING optind to POSIX_STRING_MATCHING opterr to POSIX_STRING_MATCHING optopt to POSIX_STRING_MATCHING signgam to XSI_C_LANG_SUPPORT stderr to POSIX_DEVICE_IO stdin to POSIX_DEVICE_IO stdout to POSIX_DEVICE_IO SSWG-RT will fix: daylight()->daylight in XSI_C_LANG_SUPPORT timezone()->timezone in XSI_C_LANG_SUPPORT Status: done. _____________________________________________________________________________ Page: 4 Line: 26 Section: unspecified Problem: Variables defined in Table 1-1, Units of Functionality, are handled inconsistently. The only variable listed is tzname in the POSIX_C_LANG_SUPPORT Unit of Functionality. Optarg, opterr, optind, optopt, stderr, stdin, stdout, h_errno, environ, errno, and signgam are missing. Action Change Table 1-1 to make the handling of variables more consistent. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 27 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 100) [LynuxWorks #12] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Section E.1 of POSIX.1-2001 is an informative annex which suggests an example set of units. POSIX.1-2001 defers to the profiles for the exact set to be used for profiling. The profiles are not constrained to use the set in POSIX.1-2001. In this case all profiles require threads, so there is no reason to separate thread safe functions from their non-thread safe versions. SSWG-RT could do this, but doesn't think it would add anything to 1003.13. _____________________________________________________________________________ Page: 4 Line: 26 Section: unspecified Problem: The Units of Functionality listed in Table 1-1 do not match those listed in Section E.1 of the POSIX.1 spec. A major difference is that the thread reentrant routines are not split out into XXX_R Units of Functionality as they are in POSIX.1. Action: Table 1-1 Units of Functionality should be consistent with the POSIX 1003.1 standard. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 28 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 101) [LynuxWorks #13] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The unit of functionality is not required in the same profiles as POSIX_DEVICE_IO. This is enough and needs no further explanation. The reason for individual profile requirements is in each profile chapter. _____________________________________________________________________________ Page: 7 Line: 8-9 Section: unspecified Problem: Unclear Action: POSIX_EVENT_MANAGEMENT should have a footnote, explaining why it's functionality has been split out of the POSIX_DEVICE_IO Unit of Functionality. _____________________________________________________________________________ OBJECTION Enhancement Request Number 29 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 70) [KAMP012] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add posix_devctl() in an appropriate spot, which is not here. It is wrong to include it as a POSIX.1 Unit of Functionality. Rather, it needs to be a table of its own in section 1.6 (following table 1-20, perhaps titled "Requirements for Other Standards") and be enumerated in each of the profiles in which it is required. SSWG-RT will add 1003.26 (conditionally) to the normative references, with an editorial note allowing the date of approval to be filled in once approved, or all references to 1003.26 and posix_devctl() to be removed if not approved. Status: Done. I added the new table. I also added a new subclause to each of the chapters 6-9 describing the profiles: X.2.2. POSIX.26 Requirements (C Language Option) An implementation conforming to PSE51 shall conform to POSIX.26. I also added the following paragraph to the rationale, in sections "X.6.1.5 Input and Output Primitives": The posix_devctl() function defined in POSIX.26 is required to support control operations on I/O devices. _____________________________________________________________________________ Page: 7 Line: 10 Section: Table_1-1 Problem: a link to IEEE 1003.26 (posix_devctl()) is missing Action: Add this system-call to the POSIX_FD_MGMT _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 71) [KAMP013] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: There is no need to discuss this rationale at this point. The individual profiles requiring this unit of functionality have their own rationale for the requirement. These networking calls satisfy networking requirements, not necessarily real- time requirements. The performance of implementations varies. _____________________________________________________________________________ Page: 7 Line: 28 Section: Table_ Problem: the authors of this table list most of the tcpip-service-calls in this part. A question arises whether networking of tcpip has real-time properties. Action: clarify the manner inhowfar these calls satisfy real-time requirements of the application ... _____________________________________________________________________________ EDITORIAL Enhancement Request Number 31 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 89) [LynuxWorks #1] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Once this draft is synchronized with IEEE Std 1003.1-2001 Corr 1 (See ERN 6), this unit of functionality will no longer be required (since the functions it provides will be available if either Priority Scheduling or Thread Priority Scheduling options are supported). SSWG-RT will remove this unit of functionality entirely. Status: Done. _____________________________________________________________________________ Page: 7 Line: 43 Section: unspecified Problem: POSIX_PRIORITY_RANGES does not have a footnote, explaining that it's functionality is a subset of _POSIX_PRIORITY_SCHEDULING Action Add a footnote, explaining that POSIX_PRIORITY_RANGES functionality is a subset of _POSIX_PRIORITY_SCHEDULING _____________________________________________________________________________ COMMENT Enhancement Request Number 32 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 102) [LynuxWorks #14] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Section E.1 of POSIX.1-2001 is an informative annex which suggests an example set of units. POSIX.1-2001 defers to the profiles for the exact set to be used for profiling. The profiles are not constrained to use the set in POSIX.1-2001. In this case SSWG-RT chose a more descriptive name. SSWG-RT prefers this name because it better describes the functionality of these interfaces. _____________________________________________________________________________ Page: 8 Line: 23 Section: unspecified Problem: Inconsistent usage of POSIX_C_LIB_EXT Action: The POSIX.1 spec defines POSIX_C_LIB_EXT which contains the same functions as POSIX_STRING_MATCHING which is used throughout POSIX.13. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 33 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 1) [buerger-2] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 9 Line: 5 Section: 1.4 Problem: "seteuid" should be "seteuid()" Action: make it "seteuid()" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 34 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 90) [LynuxWorks #2] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Section E.1 of POSIX.1-2001 is an informative annex which suggests an example set of units. POSIX.1-2001 defers to the profiles for the exact set to be used for profiling. The profiles are not constrained to use the set in POSIX.1-2001. In this case SSWG-RT chose a more descriptive name. SSWG-RT prefers this name because it is shorter. _____________________________________________________________________________ Page: 9 Line: 7 Section: unspecified Problem: Unit of functionality incorrectly identified Action Change POSIX_WIDE_CHAR_IO to POSIX_WIDE_CHAR_DEVICE_IO _____________________________________________________________________________ COMMENT Enhancement Request Number 35 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 80) [josey-1] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: Use Don Cragun's suggested rewording in ERN 36, as we are removing _POSIX_JOB_CONTROL as a POSIX.1 option entirely (see ERN 47). _____________________________________________________________________________ Page: 10 Line: 15 Section: 1.4 Problem: This states that there is a matching option in POSIX.1 called _POSIX_JOB_CONTROL. There is no option in IEEE Std 1003.1-2001. Its a symbolic constant. The functionality associated with it is mandatory and not optional. Action: Replace text with "This standard overloads the POSIX.1 symbolic constant _POSIX_JOB_CONTROL with a set of related functions. Support for job control is mandatory in IEEE Std 1003.1-2001" _____________________________________________________________________________ COMMENT Enhancement Request Number 36 Don Cragun Bug in 1003.13 D2.1 (rdvk# 16) [dwc-6] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 10 Line: 15-20 Section: 1.4 Problem: (_POSIX_JOB_CONTROL option) There was a job control option in earlier POSIX standards. In POSIX.1-2001 all of the functions in this group that were optional before are now mandatory, so there is no longer an option. Action: Change P10, L15-20 to: a. There was a _POSIX_JOB_CONTROL option in an earlier version of the POSIX standards that specified these functions. All of these functions are mandatory in POSIX.1. b. There was a _POSIX_REGEXP option in an earlier version of the POSIX standards that specified these functions. All of these functions are mandatory in POSIX.1. c. There was a _POSIX_READER_WRITER_LOCKS option in an earlier version of the POSIX standards that specified these functions. All of these functions are part of the _POSIX_THREADS option in POSIX.1. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 37 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 2) [buerger-3] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 16 Line: 16 Section: 1.4 Problem: reference to Annex B should be reference to Annex A Action: make it "Annex A" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 103) [LynuxWorks #15] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This reference is on page 19, not page 17; and no it isn't a typo. The name in POSIX.1 is indeed POSIX_SPIN_LOCKS! _____________________________________________________________________________ Page: 17 Line: 18 Section: unspecified Problem: Typo Action: POSIX_SPIN_LOCKS should be POSIX_SPINLOCKS _____________________________________________________________________________ EDITORIAL Enhancement Request Number 39 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 91) [LynuxWorks #3] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Once this draft is synchronized with IEEE Std 1003.1-2001 Corr 1 (See ERN 6), this unit of functionality will no longer be required (since the functions it provides will be available if either Priority Scheduling or Thread Priority Scheduling options are supported). SSWG-RT will remove this unit of functionality entirely. Status: done _____________________________________________________________________________ Page: 17 Line: 32 Section: unspecified Problem: The "-" entries in the PSE53 and PSE54 columns do not have a footnote, explaining that this functionality is a subset of _POSIX_PRIORITY_SHEDULING which is required for these profiles. Action: Add a footnote that the "-" entries in the PSE53 and PSE54 columns explaining that this functionality is a subset of_POSIX_PRIORITY_SHEDULING which is required for these profiles. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 40 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 104) [LynuxWorks #16] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Section E.1 of POSIX.1-2001 is an informative annex which suggests an example set of units. POSIX.1-2001 defers to the profiles for the exact set to be used for profiling. The profiles are not constrained to use the set in POSIX.1-2001. In this case SSWG-RT chose a more descriptive name. SSWG-RT prefers this name because it is shorter. _____________________________________________________________________________ Page: 17 Line: 46 Section: unspecified Problem: Typo Action: POSIX_WIDE_CHAR_IO should be POSIX_WIDE_CHAR_DEVICE_IO _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 Diane Schleicher Bug in 1003.13 D2.1 (rdvk# 108) [schleicher-1] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: All profiles have threads, and therefore per-thread CPU time can be measured. PSE53 and PSE54 have multiple processes; thus per-process CPU time is useful. PSE51 and PSE52 have a single implicit process, and there is no need to measure per-process CPU time in these profiles. The difference between the two options is described in POSIX.1-2001. _____________________________________________________________________________ Page: 18 Line: 39 Section: Table_1-20 Problem: _POSIX_CPUTIME is not set for PSE51 and PSE52, However, _POSIX_THREAD_CPUTIME is set all four profiles. Action: Have the two _CPUTIME options the same or specify the difference between the two options. _____________________________________________________________________________ COMMENT Enhancement Request Number 42 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 105) [LynuxWorks #17] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 19 Line: 9 Section: unspecified Problem: Incorrect definition Action: _POSIX_READER_WRITER_LOCKS should not be required for any of the profiles according to the Rationale sections for each of the individual profile: PSE51: Section 6.6.1.9 "Synchronization" on page 50 PSE52: Section 7.6.1.9 "Synchronization" on page 67 PSE53: Section 8.6.1.9 "Synchronization" on page 85 PSE54: Section 9.6.1.9 "Synchronization" on page 104 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 43 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 4) [buerger-5] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 42. Status: done _____________________________________________________________________________ Page: 19 Line: 9 Section: 1.6 Problem: Table 1-20 indicates that _POSIX_READER_WRITER_LOCKS is required for all profiles. But, the descriptions of all profiles specifically exclude it. Action: Mark _POSIX_READER_WRITER_LOCKS as "-" for all four profiles. _____________________________________________________________________________ OBJECTION Enhancement Request Number 44 Diane Schleicher Bug in 1003.13 D2.1 (rdvk# 110) [schleicher-3] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 42. Status: done _____________________________________________________________________________ Page: 19 Line: 9 Section: Table_1-20 Problem: The option _POSIX_READER_WRITER_LOCKS is specified for all four profiles. However, in sections 6.6.1.9 Synchronization, Pg. 50, Line 38; 7.6.1.9 Synchronization, Pg. 67, Line 30; 8.6.1.9 Synchronization, Pg. 85, Line 45; and 9.6.1.9 Synchronization, Pg. 104, Line 25 it specifically states that the Reader/Writer Locks are not required. Action: Either modify the 1-20 Table with the option not set for any of the profiles or modify the corresponding sections to indicate that the option is required. _____________________________________________________________________________ OBJECTION Enhancement Request Number 45 Don Cragun Bug in 1003.13 D2.1 (rdvk# 17) [dwc-7] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Old proposed resolution: SSWG-RT will delete this from this table. The associated functions are already included in the POSIX_SHELL_FUNC unit of functionality, already in another table. SSWG-RT will also delete _POSIX_SHELL from table 9-2, and add POSIX_SHELL_FUNC to table 9-3. SSWG-RT will also add another footnote to table 1-1, tied to POSIX_SHELL_FUNC, which says ("x" replaced by appropriate footnote letter): x. There was a _POSIX_SHELL option in an earlier version of the POSIX standards that specified these functions. All of these functions are mandatory in POSIX.1. Note to Technical Editor: Try to use footnote letter "d", and move all the following footnotes to the next letter. ---------------------- New Proposed resolution: SSWG-RT will delete this from this table. SSWG-RT will also delete _POSIX_SHELL from tables 1-21, 9-2, and B-2. Status: done _____________________________________________________________________________ Page: 19 Line: 16 Section: 1.6 Problem: (_POSIX_SHELL) There was a _POSIX_SHELL option in an earlier version of the POSIX standards and the symbol is retained in the current POSIX.1, but there is no such option now. All POSIX.1 implementations are required to provide the shell. Action: Delete P19, L16 (the _POSIX_SHELL entry in Table 1-20). _____________________________________________________________________________ OBJECTION Enhancement Request Number 46 Diane Schleicher Bug in 1003.13 D2.1 (rdvk# 109) [schleicher-2] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: All profiles have threads; thus per-thread Sporadic Server scheduling is useful to all profiles. PSE53 and PSE54 have multiple processes; thus per-process Sporadic Server scheduling is useful. PSE51 and PSE52 have a single implicit process; there is no need to support per-process Sporadic Server scheduling in these profiles. _____________________________________________________________________________ Page: 19 Line: 19 Section: Table_1-20 Problem: _POSIX_SPORATIC_SERVER is not set for PSE51 and PSE52, However, _POSIX_THREAD_SPORATIC_SERVER is set all four profiles. Action: Have the two _SPORATIC_SERVER options the same or specify the difference between the two options. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 47 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 3) [buerger-4] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG will delete _POSIX_JOB_CONTROL, _POSIX_REGEXP, _POSIX_READER_WRITER_LOCKS, and _POSIX_SHELL from any table in which they appear as POSIX.1 options (as indicated by the leading underscore) because they are no longer options in POSIX.1-2001. They will be addressed as units of functionality up front and in all 4 profiles. Thus _POSIX_JOB_CONTROL will not be added here as requested. See ERN 36 and ERN 45. Status: Done. Removed references to these options. Kept the units of functionality. _____________________________________________________________________________ Page: 20 Line: 37 Section: 1.6 Problem: There is no entry in Table 1-21 for _POSIX_JOB_CONTROL Action: Add it in. Presumably, the entry is "none" (I am not sufficiently familiar with POSIX.5c to know the answer). If, not, then table 9-4 on page 97 may need revision. _____________________________________________________________________________ OBJECTION Enhancement Request Number 48 Don Cragun Bug in 1003.13 D2.1 (rdvk# 18) [dwc-8] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 21 Line: 8 Section: 1.6 Problem: (_POSIX_SHELL) See also my objection dwc-7. There was a _POSIX_SHELL option in an earlier version of the POSIX standards and the symbol is retained in the current POSIX.1, but there is no such option now. All POSIX.1 implementations are required to provide the shell. Action: Delete P21, L8 (the _POSIX_SHELL entry in Table 1-21). _____________________________________________________________________________ COMMENT Enhancement Request Number 49 Don Cragun Bug in 1003.13 D2.1 (rdvk# 19) [dwc-9] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept all actions except the one asking SSWG-RT to remove the C standard from this list; instead SSWG-RT will add one or more normative references to the C standard. For action number 5, SSWG-RT will use choice A. Status: Done. Added a reference to the C standard. _____________________________________________________________________________ Page: 23-24 Line: 22-10 Section: 2.1 Problem: (normative references) There are several problems in the list of normative references. These include, but might not be limited to: 1. There are no direct references in this draft to {2}, {4}, or {5}. 2. You have lots of references to {6}, but the all seem to really be {4} as amended by {5} and {6}. 3. You incorrectly identify the standards revised by POSIX.1 and list a small subset of the amendments it includes. By listing the small subset, you call into question whether you are really referring to POSIX.1 or to the subset of .1 derived from the listed amendments. 4. By specifying that ISO/IEC8652:1995 and ISO/IEC 9899:1999 TC1 are 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 all of the following: 1. Delete P23, L24-25 (removing {2}). (You may want to move this entry, without the reference to the technical corrigenda, to the Bibliography in Subclause C.1.) 2. Delete "(Revision of IEEE Std 1003.1-1996 and IEEE Std 1003.2-1992)3" from P23, L27-28. 3. Delete footnote 3 on P23, L48. 4. Combine P23, L30-37 and P24, L1-3 into a single entry: {x} IEEE Std 1003.5-1992 as amended by IEEE Std 1003.5b-1996 and IEEE Std 1003.5c-1998, IEEE Standard for Information Technology -- POSIX Ada Language Interfaces -- Part 1: Binding for System Application Program Interface (API) as amended by Amendment 1: Realtime Extensions and Amendment 2: Protocol Independent Interfaces. 5. Do one of the following: A. delete ", including Technical Corrigendum No. 1" from P23, L22 or B. make all of the following changes: a. change "Technical Corrigendum No. 1" on P23, L22 to "all approved Technical Corrigenda". b. insert ", including all approved Technical Corrigenda" on P23, L28 before the final period. c. insert ", including all approved Technical Corrigenda" before the final period in the text specified above to replaces {4}, {5}, and {6}. d. insert ", including all approved Technical Corrigenda" on P23, L7 before e. insert ", including all approved Technical Corrigenda" on P23, L10 before the final period. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 50 Don Cragun Bug in 1003.13 D2.1 (rdvk# 20) [dwc-10] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 23 Line: 26 Section: 2.1 Problem: (year delimiter) ISO/IEC standards separate the standard number from the year it was adopted using a colon. IEEE standards separate the standard number from the year it was adopted using a hyphen as you have shown on P23, L30; P23, L33; P24, L1; and many other places in this draft. Action: Change "IEEE Std 1003.1:2001" on P23, L26 to "IEEE Std 1003.1-2001". _____________________________________________________________________________ OBJECTION Enhancement Request Number 51 Diane Schleicher Bug in 1003.13 D2.1 (rdvk# 112) [schleicher-5] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The Ada program and its relation to a process is defined in normative reference POSIX.5. No need to repeat it here. Profiles cannot redefine terms defined in base standards. _____________________________________________________________________________ Page: 26 Line: 32 Section: 3.2 Problem: Ada Program should have a definition in relation to POSIX Process. In later sections where process is the only term used, it can be confusing as to how to implement the same functionality in Ada. Action: Add Ada Program to the list of definitions and specify the definiton in terms of POSIX process. _____________________________________________________________________________ OBJECTION Enhancement Request Number 52 Diane Schleicher Bug in 1003.13 D2.1 (rdvk# 111) [schleicher-4] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The Ada program and its relation to a process is defined in normative reference POSIX.5. No need to repeat it here. Profiles cannot redefine terms defined in base standards. _____________________________________________________________________________ Page: 26 Line: 37 Section: 3.2 Problem: Ada Task should have a definition in relation to POSIX Threads. In later sections (i.e. 6.6.1.5, Input and Output Primitives) where threads is the only term used for implementing Asynchronous I/O, it can be confusing as to how to implement the same functionality in Ada. Action: Add Ada Task to the list of definitions and specify the definiton in terms of POSIX threads. _____________________________________________________________________________ OBJECTION Enhancement Request Number 53 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 72) [KAMP014] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The term "technical system" is not well defined or understood. SSWG-RT does not agree that an embedded system is also real-time. Most of them are, but not all. For example, a processor in a toy is embedded, but may have no real-time requirements. _____________________________________________________________________________ Page: 27 Line: 15 Section: 3.2.7_Embedded_Computer_System Problem: the paragraph reads: ... A computer (and its software) is considered embedded if it is an integral component of a larger system and is used to control ... Here I see a similar semantic problem as in KAMP011. Action: change the paragraph to (suggestion): A computer (...) is considered embedded if it is an .... component of a larger technical or computer system and is used to ... A remark may be allowed here: we here at IBK-Consult see that the wording "embedded system" is a synonym to "real-time system" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 54 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 73) [KAMP015] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: SSWG-RT does not agree that an embedded system is also real-time. Most of them are, but not all. For example, a processor in a toy is embedded, but may have no real-time requirements. _____________________________________________________________________________ Page: 29 Line: 18 Section: 3.3_Rationale_for_definitions Problem (not really - :) - ): definition of "embedded computer system" is a concise and very broad explanation. I like it but would suggest again as in KAMP014 the remark: "embedded system" == "real-time system" Action: add a remark like above there! _____________________________________________________________________________ COMMENT Enhancement Request Number 55 Don Cragun Bug in 1003.13 D2.1 (rdvk# 21) [dwc-11] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 31 Line: 25-31 Section: 4.1 Problem: (environment variable conventions) You don't seem to have any references to environment variables in this draft. Action: Change P31, L25-31 to: (2) The bold font is used in tables to enhance visibility of option names. _____________________________________________________________________________ COMMENT Enhancement Request Number 56 Don Cragun Bug in 1003.13 D2.1 (rdvk# 22) [dwc-12] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 31 Line: 39-42 Section: 4.1 Problem: (error numbers conventions) You don't seem to have any references to error numbers in this draft. Action: Delete P31, L39-42 and renumber the remaining conventions. _____________________________________________________________________________ COMMENT Enhancement Request Number 57 Don Cragun Bug in 1003.13 D2.1 (rdvk# 23) [dwc-13] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 31 Line: 45 Section: 4.1 Problem: (normative references convention) This draft uses a convention of referring to normative references by surrounding the normative reference number is braces. This should be described in the list of typographic conventions. Action: If my comment dwc-12 is accepted, add: (4) Normative references listed in Subclause 2.1 are represented as: {1} as a replacement for P31, L39-42. Otherwise, add it after P31, L45 with "(6)" as the label. _____________________________________________________________________________ COMMENT Enhancement Request Number 58 Don Cragun Bug in 1003.13 D2.1 (rdvk# 24) [dwc-14] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done (for all such references) _____________________________________________________________________________ Page: 32 Line: 20-22 Section: 4.2.1 Problem: (use normative references) Some of the issues raised in my comment dwc-9 applies here as well. This draft already provides a list of normative references. You should use the normative references here rather than redefining the reference. Action: Change "ISO/IEC 8652:1995 ... No. 1" on P32, L20-22 to "ISO/IEC 8652:1995 {1}". _____________________________________________________________________________ COMMENT Enhancement Request Number 59 Don Cragun Bug in 1003.13 D2.1 (rdvk# 25) [dwc-15] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will add one or more normative references to the C standard abbreviation. SSWG-RT will change "ISO/IEC 9899:1999 ... No. 1" on P32, L25-27 to "ISO/IEC 9899:1999 {2}". Status. Done. Added the references. _____________________________________________________________________________ Page: 32 Line: 25-27 Section: 4.2.2 Problem: (no references to C99 Standard abbreviation) There are no uses of the abbreviation "C99 Standard" in this draft. You don't need to define an abbreviation you don't use. Action: Delete P32, L25-27. If for some reason you decide not to make this change, at least change this abbreviation to match changes suggested to the Ada95 RM abbreviation in my comment dwc-14. _____________________________________________________________________________ COMMENT Enhancement Request Number 60 Don Cragun Bug in 1003.13 D2.1 (rdvk# 26) [dwc-16] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 3rd and 4th lines of action do not belong here. SSWG-RT assumes this is a typo in the comment. Status: done. _____________________________________________________________________________ Page: 32 Line: 28-29 Section: 4.2 Problem: (COTS abbreviation missing) You provide an abbreviation for commercial-off-the-shelf in-line in subclause 9.6.1.3 on P102, L31 and use it several times after that. All of your abbreviations should be defined in the abbreviations section. Action: Add a new abbreviation around P32, L28-29: 4.2.x COTS: commercial-off-the-shelf where {x} is the new normative reference to the POSIX.5 Standard after applying the fixes for my objection dwc-9. Change "commercial-off-the-shelf (COTS)" on P102, L31 to "COTS". _____________________________________________________________________________ COMMENT Enhancement Request Number 61 Don Cragun Bug in 1003.13 D2.1 (rdvk# 27) [dwc-17] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Note to Technical Editor: Check to see if when TC1 was applied to 1003.1-2001, didn't it's date or cititation change in some way? Status: Done. Used ISO std instead, with the requested style. _____________________________________________________________________________ Page: 32 Line: 33-35 Section: 4.2.4 Problem: (use normative references) See also my comment dwc-14. This draft already provides a list of normative references. You should use the normative references here rather than redefining the reference. ISO/IEC standards separate the standard number from the year it was adopted using a colon. IEEE standards separate the standard number from the year it was adopted using a hyphen. Action: Change "POSIX.1: IEEE Std 1003.1:2001, ... 1003.2-1992)" on P32, L33-35 to "POSIX.1: IEEE Std 1003.1-2001 {3}". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 62 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 86) [josey-7] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Yes, but SSWG-RT will add to section 2 instead, and use {3} here as per ERN 61. Status: done. _____________________________________________________________________________ Page: 32 Line: 33 Section: 4.2.4 Problem: Need to mention ISO/IEC 9945:2002 Action: Perhaps add "technically identical to ISO/IEC 9945:2002" or equivalent. _____________________________________________________________________________ OBJECTION Enhancement Request Number 63 Don Cragun Bug in 1003.13 D2.1 (rdvk# 28) [dwc-18] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In the definition of abbreviation of POSIX.5, SSWG-RT will enumerate the amendments that are included so as to exclude future amendments. This is currently {4}, {5}, and {6}, but will become something else. Status: done. _____________________________________________________________________________ Page: 32 Line: 38-45 Section: 4.2.5 Problem: (POSIX.5 versus POSIX.5c) This draft defines an abbreviation for POSIX.5c which specifies that it means IEEE Std 1003.5 as amended by IEEE Std 1003.5b and IEEE Std 1003.5c. This draft uses the undefined abbreviation "POSIX.5" dozens of times. The abbreviation "POSIX.5c" is misleading; it implies that it only refers to the IEEE Std 1003.5c amendment rather the IEEE Std 1003.5 and two amendments. All existing references in the draft to the abbreviations POSIX.5 and POSIX.5c seem to refer to IEEE Std 1003.5 and all of its amendments. See also my comments dwc-9 and dwc-14. Action: Change P32, L38-45 to: 4.2.x POSIX.5: IEEE Std 1003.5-1992 as amended {x}. Globally change all uses of the "POSIX.5c" abbreviation in this draft to "POSIX.5". _____________________________________________________________________________ COMMENT Enhancement Request Number 64 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 74) [KAMP016] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 36 Line: 11 Section: 5.1.1.2_Documentation Problem: I am not an Ada-programmer but as such I would miss a similar statement for Ada... Action: add a comment about the limits for Ada-programmers (if possible) _____________________________________________________________________________ OBJECTION Enhancement Request Number 65 Don Cragun Bug in 1003.13 D2.1 (rdvk# 29) [dwc-19] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: To deal with the first part of this objection(the "macros" issue), SSWG-RT will define feature test macros (similar to _POSIX_C_SOURCE currently set by an application to indicate that it expects to use POSIX.1), for example _POSIX_AEP_REALTIME_CONTROLLER_C_SOURCE. Presence of one of these macros will allow a POSIX.1 and profile conforming implementation to define the additional macros expected by a profile conforming application. To deal with the second part of this objection (the part following "Furthermore"), SSWG-RT will drop the requirement that _POSIX_TIMER_MAX be 64 and that _POSIX_RTSIG_MAX be 16 for profile conformance, instead requiring that TIMER_MAX have a minimum value of 64 and RTSIG_MAX have a minimum value of 16 for profile conformance. Thus we will no longer be changing "fixed" limits, but will instead be raising minimum value of limits as permitted for a profile by IEEE Std 1003.1-2001 XBD section 2.1.5.1 (Subprofiling Considerations). SSWG-RT will drop the requirement that _POSIX_NGROUPS_MAX be increased to 8, because NGROUPS_MAX already has a minimum value of 8 in POSIX.1. Status: Done. Added a feature test macro to each of the profiles. _____________________________________________________________________________ Page: 36 Line: 42-45 Section: 5.1.2 Problem: (application conformance) Any applications that conforms to any of the profiles defined in this draft is allowed to depend on macros being defined that are neither required to be nor allowed to be defined by a POSIX.1 implementation unless the application defines an unspecified feature test macro before including any header defined by POSIX.1. Furthermore, these profiles all extend minimum values for some symbols specified by POSIX.1. Again, POSIX.1 conforming applications are not allowed to depend on these extended minimums. Therefore, there can be lots of POSIX.13 profile conforming applications that are not POSIX.1 conforming applications. Action: Either remove all requirements in all profiles for all extensions to POSIX.1 or delete P36, L42-45. _____________________________________________________________________________ COMMENT Enhancement Request Number 66 Don Cragun Bug in 1003.13 D2.1 (rdvk# 30) [dwc-20] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: IEEE 1003.13-1998 is also known as ISO/IEC ISP 15287-2:2000. SSWG-RT expects this .13 revision to also become an ISO standard. Status: done. _____________________________________________________________________________ Page: 37 Line: 15-23 Section: 5.1.2.2.1 Problem: (ISO/IEC conformance) It doesn't make sense to define ISO/IEC conforming applications unless you intend for IEEE Std 1003.13 to become an ISO/IEC standard. If this revision is intended to be an ISO/IEC standard, all references to IEEE Std 1003.1-2001 should instead refer to ISO/IEC 9945:2002. (If IEEE Std 1003.5 and its amendments are ISO/IEC standards, they should also be referred to by their ISO/IEC numbers instead of their IEEE numbers.) Action: Replace references to IEEE Stds with appropriate ISO/IEC references, or delete subclause 5.1.2.2.1 and all references to ISO/IEC Conformant Applications. _____________________________________________________________________________ OBJECTION Enhancement Request Number 67 Don Cragun Bug in 1003.13 D2.1 (rdvk# 31) [dwc-21] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. Added a new constant for Ada in the POSIX_Profiles package _____________________________________________________________________________ Page: 39-40 Line: 0 Section: 6.1 Problem: (IEEE Std 1003.13 versions) There is an IEEE Std 1003.13-1998 and you are trying to create an IEEE Std 1003.13-200x. Both of them specify that _POSIX_AEP_REALTIME_MINIMAL is to be defined (with no specific value) to indicate that the implementation supports the PSE51 profile. If this symbol is defined there is no reliable way for an Ada application to determine whether the profile supported by the implementation is that specified by the 1998 standard or by this standard. A C application can guess depending on whether _POSIX_AEP_REALTIME_LANG_C89 or _POSIX_AEP_REALTIME_LANG_C99 is defined, but if an implementation implements the interfaces specified by both POSIX.13-1998 and POSIX.13-200x, there is no clear way for an application to indicate which profile is intended. Furthermore, if an implementation wants to support applications intended for both environments, this draft provides no way for an implementation's headers to define the appropriate function prototypes corresponding to the desired standard. The draft does refer to implementation-defined means to build a conforming application in subclause 6.5.1, but it should go a lot further by defining a feature test macro (or set of feature test macros) to be defined by all conforming applications before including any POSIX.1 defined headers. (This is especially important because some POSIX.1 conformance test suites are rejecting any implementations that define symbols starting with _POSIX_ unless the symbols are explicitly required by POSIX.1.) Action: Add a new paragraph in subclause 6.1.1 after P39, L35 saying something like: C-Language applications conforming to this profile shall define the feature test macro _POSIX_AEP_PSE51_C_SOURCE to be 200ymmL before any header is included. with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. Consider making a similar statement for Ada-Language applications. Change "." on P39, L45 to " to be 200ymmL." with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. _____________________________________________________________________________ OBJECTION Enhancement Request Number 68 Don Cragun Bug in 1003.13 D2.1 (rdvk# 32) [dwc-22] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 40 Line: 5-10 Section: 6.1.3 Problem: (unclear specification) See also my objection dwc-21. The Ada half of the requirement here is clear: if the boolean symbols are true, then the corresponding option is supported. The C half is not clear: if the symbols are defined, something unspecified is indicated. Action: Change ":" on P40, L6 to ", then a corresponding programming environment is supported:". _____________________________________________________________________________ COMMENT Enhancement Request Number 69 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 85) [josey-6] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will use "POSIX.1 Interfaces" instead. SSWG-RT will extend this notation to all headings x.2.y, where the word "Requirements" is currently (mis)used. Status: done _____________________________________________________________________________ Page: 40 Line: 25 Section: 6.2.1 Problem: This heading implies these are requirements for POSIX.1, and could be more clearly stated as "POSIX.13 Requirements drawn from POSIX.1 (C Language) Action: change as noted above _____________________________________________________________________________ EDITORIAL Enhancement Request Number 70 Diane Schleicher Bug in 1003.13 D2.1 (rdvk# 113) [schleicher-6] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 40 Line: 35 Section: Table_6-1 Problem: POSIX_C_LIB_EXT is defined for the PSE51 profile. However, this is hot a defined Unit of Functionality in Table 1-19, Pg. 17. Action: Remove the table entry, POSIX_C_LIB_EXT. _____________________________________________________________________________ OBJECTION Enhancement Request Number 71 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 92) [LynuxWorks #4] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 70 _____________________________________________________________________________ Page: 40 Line: 35-36 Section: unspecified Problem: POSIX_C_LIB_EXT is listed as a requirement for PSE51. It is not listed in any previous tables (1-1 or 1-19). It is also not listed as a requirement for PSE52, PSE53 or PSE54. Action Delete POSIX_C_LIB_EXT as a requirement for PSE51 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 72 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 5) [buerger-6] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 70 _____________________________________________________________________________ Page: 40 Line: 36 Section: 6.2.1 Problem: Unit of Functionality POSIX_C_LIB_EXT appearing in table 6-1 does not appear in table 1-1. Action: I am not sure what is intended here. Is something missing from table 1-1? Perhaps this entry just should be deleted from table 6-1. _____________________________________________________________________________ OBJECTION Enhancement Request Number 73 Don Cragun Bug in 1003.13 D2.1 (rdvk# 33) [dwc-23] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 41 Line: 1-13 Section: 6.2.1 Problem: (requirements unclear and inconsistent with POSIX.1) POSIX.1 no longer has a _POSIX_NO_TRUNC option; it is now required behavior. For backwards compatibility, POSIX.1 requires that _POSIX_NO_TRUNC have a value other than -1, but does not require it to be greater than zero. I see no justification for this draft to require a more stringent setting of this symbol than is required by POSIX.1. The meaning of "by defining the associated symbol" is ambiguous. In POSIX.1 these symbols can be defined in or the value can be determined by using sysconf() if the symbol is not defined or has value 0 in . Again, I see no justification for this draft to require a more stringent setting of these symbols than is required by POSIX.1. Action: Change P41, L1-3 to: An implementation supporting the Minimal Realtime System Profile shall support the following POSIX.1 options: Delete _POSIX_NO_TRUNC from P41, L13. _____________________________________________________________________________ COMMENT Enhancement Request Number 74 Andrew Josey Bug in 1003.13 D2.1 (rdvk# 84) [josey-5] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SSWG-RT will use "POSIX.1 Interfaces" instead. SSWG-RT will extend this notation to all headings x.2.y, where the word "Requirements" is currently (mis)used. This is similar to ERN 69. Status: done _____________________________________________________________________________ Page: 42 Line: 1 Section: 6.2.2 Problem: This heading implies these are requirements for POSIX.5c, and could be more clearly stated as "POSIX.13 Requirements drawn from POSIX.5c (Ada Language) Action: change as noted above _____________________________________________________________________________ EDITORIAL Enhancement Request Number 75 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 6) [buerger-7] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The correct name is "Mutexes". SSWG-RT will also insert an entry in Table 1-21 (although threads are implicit in Ada, mutexes are not; mutexes are not a distinct option in C, but part of _POSIX_THREADS.) Status: done _____________________________________________________________________________ Page: 42 Line: 32 Section: 6.2.2 Problem: It is unclear to what the entry "Mutexes Support" refers. Every other entry in table 6-4 has a corresponding entry in table 1-21. Perhaps the reference is to the package Mutexes in table B-3 on page 124. This issue also arises in table 7-4 on page 60 and in table 8-4 on page 79 and in table 9-4 on page 98 where it is called "Mutexes Supported." Action: If the reference is to package Mutexes, just call it "Mutexes." If not, then clarify the reference. In any event, use the same terminology in table 9-4 as in the other tables unless it is really different in table 9-4 - in which case, I really do not know what is going on :-) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 76 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 9) [buerger-10] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 44 Line: 20 Section: 6.3.1 Problem: A misplaced plural. This also appears on page 62 line 20. Action: Change "this profiles does" to "this profile does." _____________________________________________________________________________ OBJECTION Enhancement Request Number 77 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 75) [KAMP017] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 44 Line: 27 Section: 6.3.1_Constraints Problem: in the line with the C-Manifest "S-IRWXU" there should be no "-" character (minus-sign) Action: change C-Manifest to "S_IRWXU" - use underscore!! _____________________________________________________________________________ COMMENT Enhancement Request Number 78 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 76) [KAMP018] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This normative part of the standard cannot make "remarks", only state requirements. Please note that although a shell is not required it can be provided as an option by any PSE51 implementation. _____________________________________________________________________________ Page: 46 Line: 23 Section: 6.4_Shell_and_Utility Problem: the committee omitted the shell. it could be favourable for debugging also in post-installation situations to have at least a micro-shell Action: add a remark on installation of a "micro-shell" _____________________________________________________________________________ OBJECTION Enhancement Request Number 79 Don Cragun Bug in 1003.13 D2.1 (rdvk# 34) [dwc-24] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done for all the document. _____________________________________________________________________________ Page: 46 Line: 40 Section: 6.5.1 Problem: (POSIX2_C_BIND option) There is no POSIX2_C_BIND option in POSIX.1 since the revision. All of the functions that were defined as optional in POSIX.2-1992 are mandatory features in POSIX.1-2001. Action: Delete "POSIX2_C_BIND, " from P46, L40. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 80 Don Cragun Bug in 1003.13 D2.1 (rdvk# 35) [dwc-25] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 47 Line: 5 Section: 6.5.1.1 Problem: (extraneous word) On P47, L32 you specify that _POSIX_AEP_REALTIME_LANG_Ada95 being "defined in the header " indicates that Ada Language Development Option is available. On P47, L5 you say "defined in the required header " instead of "defined in the header ". The "required" doesn't add anything. Action: Delete "required " on P47, L5. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 81 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 7) [buerger-8] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done. _____________________________________________________________________________ Page: 48 Line: 40 Section: 6.6.1.2 Problem: The "up" in "up to" is superfluous and may be misleading - allowing values between 8 and 16. This issue also appears on pages: 52, line 46; 65, line 33; 70, line 5; 83, line 35; 88, line 22; 102, line 16; 107, line 11. Action: Change "up to" to "to." _____________________________________________________________________________ COMMENT Enhancement Request Number 82 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 77) [KAMP019] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This term is defined in POSIX.1 in 3.331 of volume XBD. It is not repeated in this standard. Profiles cannot redefine terms defined in base standards. _____________________________________________________________________________ Page: 51 Line: 28 Section: 6.6.1.10_PriorityScheduling Problem: the term "scheduling allocation domain" is not generally known. Therefore there should be a remark or definition of that term Action: add an entry to the glossary for "scheduling allocation domain" _____________________________________________________________________________ OBJECTION Enhancement Request Number 83 Joerg Kampmann Bug in 1003.13 D2.1 (rdvk# 78) [KAMP020] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The working group and the majority of the ballot group (manifested through their ballots) preferred keeping the minimal profile as small as possible. Please note that although POSIX tracing is not required it can be provided as an option by any PSE51 implementation. _____________________________________________________________________________ Page: 53 Line: 34 Section: 6.6.1.16_tracing Problem: the authors of the standard argue that tracing is not necessary for PSE51. I think tracing is necessary for the same reasons as pointed out a bit later for PSE52/3/4 in 7.6.1.16 (page 70, line 34-44) Action: include tracing capability also for PSE51 _____________________________________________________________________________ OBJECTION Enhancement Request Number 84 Don Cragun Bug in 1003.13 D2.1 (rdvk# 36) [dwc-26] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 67. Status: done _____________________________________________________________________________ Page: 57-58 Line: 0 Section: 7.1 Problem: (IEEE Std 1003.13 versions) See also my objection dwc-21. There is an IEEE Std 1003.13-1998 and you are trying to create an IEEE Std 1003.13-200x. Both of them specify that _POSIX_AEP_REALTIME_CONTROLLER is to be defined (with no specific value) to indicate that the implementation supports the PSE52 profile. If this symbol is defined there is no reliable way for an Ada application to determine whether the profile supported by the implementation is that specified by the 1998 standard or by this standard. A C application can guess depending on whether _POSIX_AEP_REALTIME_LANG_C89 or _POSIX_AEP_REALTIME_LANG_C99 is defined, but if an implementation implements the interfaces specified by both POSIX.13-1998 and POSIX.13-200x, there is no clear way for an application to indicate which profile is intended. Furthermore, if an implementation wants to support applications intended for both environments, this draft provides no way for an implementation's headers to define the appropriate function prototypes corresponding to the desired standard. The draft does refer to implementation-defined means to build a conforming application in subclause 7.5.1, but it should go a lot further by defining a feature test macro (or set of feature test macros) to be defined by all conforming applications before including any POSIX.1 defined headers. (This is especially important because some POSIX.1 conformance test suites are rejecting any implementations that define symbols starting with _POSIX_ unless the symbols are explicitly required by POSIX.1.) Action: Add a new paragraph in subclause 7.1.1 after P57, L34 saying something like: C-Language applications conforming to this profile shall define the feature test macro _POSIX_AEP_PSE52_C_SOURCE to be 200ymmL before any header is included. with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. Consider making a similar statement for Ada-Language applications. Change "." on P57, L44 to " to be 200ymmL." with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. _____________________________________________________________________________ OBJECTION Enhancement Request Number 85 Don Cragun Bug in 1003.13 D2.1 (rdvk# 37) [dwc-27] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 73. Status: done _____________________________________________________________________________ Page: 59 Line: 1-15 Section: 7.2.1 Problem: (requirements unclear and inconsistent with POSIX.1) POSIX.1 no longer has a _POSIX_NO_TRUNC option; it is now required behavior. For backwards compatibility, POSIX.1 requires that _POSIX_NO_TRUNC have a value other than -1, but does not require it to be greater than zero. I see no justification for this draft to require a more stringent setting of this symbol than is required by POSIX.1. The meaning of "by defining the associated symbol" is ambiguous. In POSIX.1 these symbols can be defined in or the value can be determined by using sysconf() if the symbol is not defined or has value 0 in . Again, I see no justification for this draft to require a more stringent setting of these symbols than is required by POSIX.1. Action: Change P59, L1-3 to: An implementation supporting the Realtime Controller System Profile shall support the following POSIX.1 options: Delete _POSIX_NO_TRUNC from P59, L15. _____________________________________________________________________________ OBJECTION Enhancement Request Number 86 Don Cragun Bug in 1003.13 D2.1 (rdvk# 38) [dwc-28] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 79. Status: done _____________________________________________________________________________ Page: 63 Line: 34 Section: 7.5.1 Problem: (POSIX2_C_BIND option) There is no POSIX2_C_BIND option in POSIX.1 since the revision. All of the functions that were defined as optional in POSIX.2-1992 are mandatory features in POSIX.1-2001. Action: Delete "POSIX2_C_BIND, " from P63, L34. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 87 Don Cragun Bug in 1003.13 D2.1 (rdvk# 39) [dwc-29] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 63 Line: 43 Section: 7.5.1.1 Problem: (extraneous word) On P64, L21-22 you specify that _POSIX_AEP_REALTIME_LANG_Ada95 being "defined in the header " indicates that Ada Language Development Option is available. On P63, L43-44 you say "defined in the required header " instead of "defined in the header ". The "required" doesn't add anything. Action: Delete "required " on P63, L43. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 88 Don Cragun Bug in 1003.13 D2.1 (rdvk# 40) [dwc-30] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 66 Line: 4 Section: 7.6.1.4 Problem: (number mismatch) The "a" is singular, but "file systems" is plural. Action: Change "a basic file systems" on P66, L4-5 to "basic file systems". _____________________________________________________________________________ OBJECTION Enhancement Request Number 89 Don Cragun Bug in 1003.13 D2.1 (rdvk# 41) [dwc-31] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 67. Status: done _____________________________________________________________________________ Page: 75-76 Line: 0 Section: 8.1 Problem: (IEEE Std 1003.13 versions) See also my objection dwc-21. There is an IEEE Std 1003.13-1998 and you are trying to create an IEEE Std 1003.13-200x. Both of them specify that _POSIX_AEP_REALTIME_DEDICATED is to be defined (with no specific value) to indicate that the implementation supports the PSE53 profile. If this symbol is defined there is no reliable way for an Ada application to determine whether the profile supported by the implementation is that specified by the 1998 standard or by this standard. A C application can guess depending on whether _POSIX_AEP_REALTIME_LANG_C89 or _POSIX_AEP_REALTIME_LANG_C99 is defined, but if an implementation implements the interfaces specified by both POSIX.13-1998 and POSIX.13-200x, there is no clear way for an application to indicate which profile is intended. Furthermore, if an implementation wants to support applications intended for both environments, this draft provides no way for an implementation's headers to define the appropriate function prototypes corresponding to the desired standard. The draft does refer to implementation-defined means to build a conforming application in subclause 8.5.1, but it should go a lot further by defining a feature test macro (or set of feature test macros) to be defined by all conforming applications before including any POSIX.1 defined headers. (This is especially important because some POSIX.1 conformance test suites are rejecting any implementations that define symbols starting with _POSIX_ unless the symbols are explicitly required by POSIX.1.) Action: Add a new paragraph in subclause 8.1.1 after P75, L34 saying something like: C-Language applications conforming to this profile shall define the feature test macro _POSIX_AEP_PSE53_C_SOURCE to be 200ymmL before any header is included. with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. Consider making a similar statement for Ada-Language applications. Change "." on P75, L45 to " to be 200ymmL." with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. _____________________________________________________________________________ OBJECTION Enhancement Request Number 90 Don Cragun Bug in 1003.13 D2.1 (rdvk# 42) [dwc-32] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 76 Line: 5-10 Section: 8.1.3 Problem: (unclear specification) See also my objection dwc-21. The Ada half of the requirement here is clear: if the boolean symbols are true, then the corresponding option is supported. The C half is not clear: if the symbols are defined, something unspecified is indicated. Action: Change ":" on P76, L6 to ", then a corresponding programming environment is supported:". _____________________________________________________________________________ OBJECTION Enhancement Request Number 91 Don Cragun Bug in 1003.13 D2.1 (rdvk# 43) [dwc-33] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 73. Status: done _____________________________________________________________________________ Page: 77 Line: 6-23 Section: 8.2.1 Problem: (requirements unclear and inconsistent with POSIX.1) POSIX.1 no longer has a _POSIX_NO_TRUNC option; it is now required behavior. For backwards compatibility, POSIX.1 requires that _POSIX_NO_TRUNC have a value other than -1, but does not require it to be greater than zero. I see no justification for this draft to require a more stringent setting of this symbol than is required by POSIX.1. The meaning of "by defining the associated symbol" is ambiguous. In POSIX.1 these symbols can be defined in or the value can be determined by using sysconf() if the symbol is not defined or has value 0 in . Again, I see no justification for this draft to require a more stringent setting of these symbols than is required by POSIX.1. Action: Change P77, L6-8 to: An implementation supporting the Dedicated Realtime System Profile shall support the following POSIX.1 options: Delete _POSIX_NO_TRUNC from P77, L23. _____________________________________________________________________________ OBJECTION Enhancement Request Number 92 Don Cragun Bug in 1003.13 D2.1 (rdvk# 44) [dwc-34] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 79. Status: done _____________________________________________________________________________ Page: 81 Line: 42 Section: 8.5.1 Problem: (POSIX2_C_BIND option) There is no POSIX2_C_BIND option in POSIX.1 since the revision. All of the functions that were defined as optional in POSIX.2-1992 are mandatory features in POSIX.1-2001. Action: Delete "POSIX2_C_BIND, " from P81, L42. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 93 Don Cragun Bug in 1003.13 D2.1 (rdvk# 45) [dwc-35] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 82 Line: 5 Section: 8.5.1.1 Problem: (extraneous word) On P82, L32 you specify that _POSIX_AEP_REALTIME_LANG_Ada95 being "defined in the header " indicates that Ada Language Development Option is available. On 82, L5 you say "defined in the required header " instead of "defined in the header ". The "required" doesn't add anything. Action: Delete "required " on P82, L5. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 94 Don Cragun Bug in 1003.13 D2.1 (rdvk# 46) [dwc-36] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 84 Line: 8 Section: 8.6.1.4 Problem: (number mismatch) The "a" is singular, but "file systems" is plural. Action: Change "a basic file systems" on P84, L8-9 to "basic file systems". _____________________________________________________________________________ OBJECTION Enhancement Request Number 95 Don Cragun Bug in 1003.13 D2.1 (rdvk# 47) [dwc-37] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 67. Status: done _____________________________________________________________________________ Page: 93-94 Line: 0 Section: 9.1 Problem: (IEEE Std 1003.13 versions) See also my objection dwc-21. There is an IEEE Std 1003.13-1998 and you are trying to create an IEEE Std 1003.13-200x. Both of them specify that _POSIX_AEP_REALTIME_MULTI is to be defined (with no specific value) to indicate that the implementation supports the PSE54 profile. If this symbol is defined there is no reliable way for an Ada application to determine whether the profile supported by the implementation is that specified by the 1998 standard or by this standard. A C application can guess depending on whether _POSIX_AEP_REALTIME_LANG_C89 or _POSIX_AEP_REALTIME_LANG_C99 is defined, but if an implementation implements the interfaces specified by both POSIX.13-1998 and POSIX.13-200x, there is no clear way for an application to indicate which profile is intended. Furthermore, if an implementation wants to support applications intended for both environments, this draft provides no way for an implementation's headers to define the appropriate function prototypes corresponding to the desired standard. The draft does refer to implementation-defined means to build a conforming application in subclause 9.5.1, but it should go a lot further by defining a feature test macro (or set of feature test macros) to be defined by all conforming applications before including any POSIX.1 defined headers. (This is especially important because some POSIX.1 conformance test suites are rejecting any implementations that define symbols starting with _POSIX_ unless the symbols are explicitly required by POSIX.1.) Action: Add a new paragraph in subclause 9.1.1 after P93, L35 saying something like: C-Language applications conforming to this profile shall define the feature test macro _POSIX_AEP_PSE54_C_SOURCE to be 200ymmL before any header is included. with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. Consider making a similar statement for Ada-Language applications. Change "." on P93, L44 to " to be 200ymmL." with a note indicating that 200ymmL will be adjusted when this draft is approved by the IEEE Standards Board to indicate the year and month of approval. _____________________________________________________________________________ OBJECTION Enhancement Request Number 96 Don Cragun Bug in 1003.13 D2.1 (rdvk# 48) [dwc-38] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 94 Line: 5-10 Section: 9.1.3 Problem: (unclear specification) See also my objection dwc-21. The Ada half of the requirement here is clear: if the boolean symbols are true, then the corresponding option is supported. The C half is not clear: if the symbols are defined, something unspecified is indicated. Action: Change ":" on P94, L6 to ", then a corresponding programming environment is supported:". _____________________________________________________________________________ OBJECTION Enhancement Request Number 97 Don Cragun Bug in 1003.13 D2.1 (rdvk# 49) [dwc-39] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 73. Status: done _____________________________________________________________________________ Page: 95 Line: 21-40 Section: 9.2.1 Problem: (requirements unclear and inconsistent with POSIX.1) POSIX.1 no longer has a _POSIX_NO_TRUNC option; it is now required behavior. For backwards compatibility, POSIX.1 requires that _POSIX_NO_TRUNC have a value other than -1, but does not require it to be greater than zero. I see no justification for this draft to require a more stringent setting of this symbol than is required by POSIX.1. The meaning of "by defining the associated symbol" is ambiguous. In POSIX.1 these symbols can be defined in or the value can be determined by using sysconf() if the symbol is not defined or has value 0 in . Again, I see no justification for this draft to require a more stringent setting of these symbols than is required by POSIX.1. Action: Change P95, L21-23 to: An implementation supporting the Multi-Purpose Realtime System Profile shall support the following POSIX.1 options: Delete _POSIX_NO_TRUNC from P95, L40. _____________________________________________________________________________ OBJECTION Enhancement Request Number 98 Don Cragun Bug in 1003.13 D2.1 (rdvk# 50) [dwc-40] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 96 Line: 4 Section: 9.2.1 Problem: (_POSIX_SHELL) See also my objection dwc-7. There was a _POSIX_SHELL option in an earlier version of the POSIX standards and the symbol is retained in the current POSIX.1, but there is no such option now. All POSIX.1 implementations are required to provide the shell. Action: Delete P96, L4 (the _POSIX_SHELL entry in Table 9-2). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 99 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 106) [LynuxWorks #18] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The reason for not mentioning it in Table 1-20 is that the operations under this option are defined in other units of functionality. _____________________________________________________________________________ Page: 96 Line: 15 Section: unspecified Problem: Incorrect references Action: _POSIX_THREAD_SAFE_FUNCTIONS is listed in this table, but not in the corresponding spot in Table 1-20, line 29, on page 19. _____________________________________________________________________________ OBJECTION Enhancement Request Number 100 Don Cragun Bug in 1003.13 D2.1 (rdvk# 51) [dwc-41] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 79. Status: done _____________________________________________________________________________ Page: 99 Line: 43 Section: 9.4 Problem: (_POSIX2_C_BIND) There is no POSIX2_C_BIND option in POSIX.1 since the revision. All of the functions that were defined as optional in POSIX.2-1992 are mandatory features in POSIX.1-2001. Action: Delete P99, L43 from Table 9.5 (the POSIX2_C_BIND entry). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 101 Don Cragun Bug in 1003.13 D2.1 (rdvk# 52) [dwc-42] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 99 Line: 44 Section: 9.4 Problem: (POSIX2_C_DEV) Missing underscore. Action: Change "POSIX2_CDEV" on P99, L44 to "POSIX2_C_DEV". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 102 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 93) [LynuxWorks #5] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 101. Status: done _____________________________________________________________________________ Page: 99 Line: 44 Section: unspecified Problem: Typo Action Replace _POSIX2_CDEV with _POSIX2_C_DEV. _____________________________________________________________________________ OBJECTION Enhancement Request Number 103 Don Cragun Bug in 1003.13 D2.1 (rdvk# 53) [dwc-43] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Similar to ERN 79. Status: done _____________________________________________________________________________ Page: 100 Line: 27 Section: 9.5.1 Problem: (POSIX2_C_BIND option) There is no POSIX2_C_BIND option in POSIX.1 since the revision. All of the functions that were defined as optional in POSIX.2-1992 are mandatory features in POSIX.1-2001. Action: Delete "POSIX2_C_BIND, " from P100, L27. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 104 Don Cragun Bug in 1003.13 D2.1 (rdvk# 54) [dwc-44] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 100 Line: 36 Section: 9.5.1.1 Problem: (extraneous word) On P101, L15 you specify that _POSIX_AEP_REALTIME_LANG_Ada95 being "defined in the header " indicates that Ada Language Development Option is available. On 100, L36-37 you say "defined in the required header " instead of "defined in the header ". The "required" doesn't add anything. Action: Delete "required " on P100, L36. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 105 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 94) [LynuxWorks #6] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 102 Line: 44 Section: 9.6.1.4 Problem: Grammer Action Please add the word "it" between "which" and "is". "... hints about the way in which IT is going to perform ..." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 106 Paul Buerger Bug in 1003.13 D2.1 (rdvk# 8) [buerger-9] _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: See ERN 105 Status: done _____________________________________________________________________________ Page: 102 Line: 44 Section: 9.6.1.4 Problem: an "it" seems to be missing. Action: Change "which is going" to "which it is going." _____________________________________________________________________________ COMMENT Enhancement Request Number 107 Don Cragun Bug in 1003.13 D2.1 (rdvk# 55) [dwc-45] _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Also see ERN 31; this unit of functionality will go away completely. Status: not applicable to current document _____________________________________________________________________________ Page: 104 Line: 41-42 Section: 9.6.1.10 Problem: (POSIX_PRIORITY_RANGES not required) The statement "The POSIX_PRIORITY_RANGES unit of functionality is not required ..." on P104, L41-42 is misleading. This profile requires the POSIX.1 _POSIX_PRIORITY_SCHEDULING option which includes everything in this unit of functionality. Action: Change "is not required" on P104, L41-42 to "is required indirectly". _____________________________________________________________________________ COMMENT Enhancement Request Number 108 Arun Subbarao Bug in 1003.13 D2.1 (rdvk# 95) [LynuxWorks #7] _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Status: done _____________________________________________________________________________ Page: 109 Line: 39-40 Section: 9.6.2 Problem: Rationale unclear Action This rationale needs clarification. As worded, it suggests that all functionality from the Shell and Utilities Volume of POSIX.1 (including optional functionality) is required by PSE54. Section 9.4 lists a subset of the optional functionality that is required. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 109 Joerg Kampmann Bug in 100