X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P1 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ 0 o 1 1 Sect 0 OBJECTION. page 0, line 0: Problem: (Drop newly invented fts().) I don't find any of the arguments for inventing this new interface convincing. Given the large number of implementations based on System V and/or that conform to various Open Group X/Open Portability Guide and/or Single UNIX Specification requirements for providing nftw(), and the large number of applications that use the nftw() interface, I think we would be much better off replacing fts() with nftw() from "CAE Specification-System Interfaces and Headers, Issue 5" (XSH5). Action: Replace the reference to on P13, L277-278, (subclause 2.7.2), with namespace reservations from XSH5 for (moved into the appropriate sorted order). Change the reference to on P15, L365-366, (subclause 2.7.3), to refer to providing a prototype for nftw() as in XSH5 (moved into the appropriate sorted order). Replace P60-71, L590-1024, (clause 5.8), with the description of nftw() from XSH5. Replace P108-124, L705-862, (subclause B.5.8), with a discussion of how to use nftw(). Replace P142, L24-45, (Annex C discussion of ), with a description of the contents of from XSH5. I will also accept dropping all mention of fts() from the draft (instead of replacing it with nftw()) as a way of satisfying this objection. ------------------------------------------------------------------------------ @ 0 o 2 2 Sect 0 OBJECTION. page 0, line 0: Problem: (thread-safety) The additions/changes to the specification need to take into account behaviour on systems that support threads - see IEEE Std 1003.1-1996 section 2.3.9 thread-safety. Action: Consider each new interface and note whether it is required to be thread-safe. I believe this is limited to a single function getenv(), however due to objection number 1 I have not assessed the fts() functions. On page 29 section 4.6.1.2 getenv() DESCRIPTION Add after line 150 The getenv() function need not be thread-safe. The rationale is that functions such as getenv() which may return values pointing to static data are inherently not reentrant. X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P2 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ 0 c 3 3 Sect 0 EDITORIAL COMMENT. page 0 line 7-8: Problem: Page iv line 7-8 Whilst not part of the normative standard the front matter needs some rework - in particular this sentence does not make sense, remove the "be" Action: Change "In addition, the corrigenda to ISO/IEC 9945-1:1990 is also be included in this document." to "In addition, the corrigenda to ISO/IEC 9945-1:1990 is also included in this document." ------------------------------------------------------------------------------ @ 0 c 4 4 Sect 0 EDITORIAL COMMENT. Page 0, Line 33-47: Problem: Page v lines 33-47 Whilst not part of the normative standard the front matter needs some rework - in particular its not clear that all of these projects are active particularly (6) Secure/Trusted Systems considerations, (9) Graphical User Interfaces Action: Delete (6) and (9) ------------------------------------------------------------------------------ @ 0 c 5 5 Sect 0 EDITORIAL COMMENT. page 0, line 83: Problem: (Typo in Change History.) On line 83 of the 5th unnumbered page in the draft "Major" is misspelled. Action: Change "Majpr" to "Major". X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P3 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ 1.2 c 6 6 Sect 1.2 EDITORIAL COMMENT. page 2, line 19: Problem: Incorrect reference to ISO/IEC 10646 Action: Change from "ISO/IEC 10646:1992 Information technology - Universal Coded Character Set (UCS)" to "ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane" ------------------------------------------------------------------------------ @ 2.2 c 7 7 Sect 2.2.2.83 EDITORIAL COMMENT. page 7, line 81: Problem: (Noun/verb mismatch.) There is a singular noun (effective group ID), with a plural verb (do). Action: Change "the effective group ID do" on P7, L81 to "the effective group ID does". ------------------------------------------------------------------------------ @ 2.2 c 8 8 Sect 2.2.2 EDITORIAL COMMENT. page 9, line 137: Problem: (Extraneous period.) There is an extra period between the referenced document and its document number. Action: Change "C Standard. {2}." on P9, L137 to "C Standard {2}.". ------------------------------------------------------------------------------ @ 2.3 c 9 9 Sect 2.3.6 EDITORIAL COMMENT. page 10, line 183-184: Problem: (Errors aren't returned.) When an error occurs, errno is set to indicate what error was detected, but the return value doesn't reflect the value assigned to errno. Action: Change "[ENAMETOOLONG] shall be returned" on P10, L183-184 "errno shall be set to [ENAMETOOLONG] and an error indication shall be returned". X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P4 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ 2.4 o 10 10 Sect 2.4 OBJECTION. page 12, line 240: Problem: Having a hard link to a directory is very different to a directory being empty. If this definition is changed as indicated, no directory could ever be removed by rmdir(). Except for the root directory of a filesystem, an empty directory has two hard links ("." in the directory and its name in its parent directory). The only place where two hard links to a directory are named "." and ".." is in the root directory. Also see objection number 16. Action: Remove this section , delete 238-241 ------------------------------------------------------------------------------ @ 2.8 o 11 11 Sect 2.8.5 OBJECTION. page 18, line 450-452: Problem: (SYMLOOP_MAX unusable as a pathname variable value.) If SYMLOOP_MAX can vary from directory to directory, it will be too complicated to use. Any application wanting to create a symlink would have to know all of the directories that could contain a symbolic link in a chain of symbolic links, ask pathconf() to get the value of SYMLOOP_MAX for each of those directories, and verify that no more than the minimum number supported by any directory in the chain was exceeded. Historic implementations haven't needed this value. It seems that applications trying to use it will be extremely complicated. Portable applications are already restricted to using no more than 8 symbolic links in a chain. I know a lot of software developers are creative, but I don't see any need for an application to request the value of SYMLOOP_MAX to decide how long to make chains of symbolic links. Action: Delete all references to SYMLOOP_MAX and _POSIX_SYMLOOP_MAX and instead just require that all conforming implementations support chains of symbolic links involving at least eight symbolic links that don't form a loop. ------------------------------------------------------------------------------ @ 3 c 12 12 Sect 3 COMMENT. page 21,23,24, line 2,15,75,91,94,97: Problem: (Ambiguous change specifications.) Just saying "Add and to the Synopsis." doesn't specify where they are to be added in the synopsis or the order in which they are to be added. Action: Clearly state that and are to be added in that order to the start of the Synopsis section on P21, L2; P21, L15; P23, L75; P24, L91; P24, L94; and P24, L97. X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P5 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ 4.2 o 13 13 Sect 4.2.2.2 OBJECTION. page 25, line 22-58: Problem: (text format confusing) The format for the description of these functions is confusing. For the clause commencing on line 22 "For the setuid()...", its not clear where this ends. Action: Remove line 22 Indent lines 23-42 including the Otherwise clause. ------------------------------------------------------------------------------ @ 4.2 o 14 14 Sect 4.2.2.2 OBJECTION. page 26, line 45: Problem: (ambiguous text) Does the clause "Whether or not {_POSIX_SAVED_IDS} is defined,".. apply to the 2nd sentence (commencing "If the process has appropriate.." in this paragraph? Its not clear whether it does or not. Action: Make this unambiguous by breaking out the clause to "Whether or not {_POSIX_SAVED_IDS} is defined:" {rest of paragraph should be here and indented} ------------------------------------------------------------------------------ @ 4.6 c 15 15 Sect 4.6 EDITORIAL COMMENT. page 29, line 138: Problem: (incorrect reference) Is the reference to 2.7 correct? Action: Probably this should change to refer to 2.6 Environment Description ------------------------------------------------------------------------------ @ 5.5 o 16 16 Sect 5.5.2.2 OBJECTION. page 48, line 262-263: Problem: (Can't remove any directory.) If this change is accepted as written, rmdir() will not be allowed to remove any directory (with the possible exception of a filesystem root directory). A normally connected empty directory has two hard links "." in the directory itself and its name in its parent directory. The entry for dot-dot in a directory is not a hard link to that directory except in the root directory of a filesystem. Action: On page 48, replace lines 262-263 with "If there are not exactly two hard links to a directory including one named dot, then rmdir() shall fail and set errno to [EEXIST] or [ENOTEMPTY]" X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P6 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ 5.6 o 17 17 Sect 5.6.7.2 OBJECTION. page 57, line 541-542: Problem: (No requested change.) These lines identify a place in POSIX.1-1990 that is supposed to be changed, but no change is specified. Action: Based on the following rationale, Change '(1003.1b: line 1020) "Otherwise:"' on P57, L542 to '(1003.1b: lines 1020-1022) Delete the line containing "Otherwise:" and the following paragraph.'. ------------------------------------------------------------------------------ @ 5.7 o 18 18 Sect 5.7.1.3 OBJECTION. page 58, line 569: Problem: (SYMLINK_MAX only associated with a directory.) Since pathconf() follows symbolic links and there is no way in the standard to get an open file descriptor connected to a symbolic link, there is no way to invoke pathconf() or fpathconf() on a symbolic link. It doesn't make sense to request the maximum length of the string that can be stored in a symbolic link for any file type except for a directory or for a symbolic link. Action: Change "(8)" on P58, L569 to "(4)(8)". ------------------------------------------------------------------------------ @ 5.7 o 19 19 Sect 5.7.1.3 OBJECTION. page 58, line 570: Problem: (SYMLOOP_MAX unusable as a pathname variable value.) See also my objection number 11. Also note (8) makes no sense as written. (SYMLOOP_MAX has nothing to do with the number of characters in a symbolic link.) Action: Delete P58, L570 ------------------------------------------------------------------------------ @ 6 c 20 20 Sect 6 COMMENT. page 73,74, line 10,12,14-16,42: Problem: (Ambiguous change specifications.) See also my comment number 12. Although the problem is less severe here than it was in section 3, the instructions for where is to be added in the synopses could be misinterpreted here as well. Action: Change "Add to the Synopsis" on P73, L10; P73, L12; P73, L15-16; P73, L17-18; and P74, L42-43 to "Add at the top of the Synopsis". X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P7 of 7 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1a/D14 ------------------------------------------------------------------------------ @ B.2 c 21 21 Sect B.2.8.2 EDITORIAL COMMENT. page 108, line 189-191: Problem: (Wrong indentation.) This paragraph is talking about a numeric limit minimum value, but it is not related to _POSIX_LINK_MAX. Action: Outdent the paragraph on P108, L189-191. ------------------------------------------------------------------------------ @ B.5 c 22 22 Sect B.5.8.2 EDITORIAL COMMENT. page 121, line 754: Problem: Typo Action: change "rathan" -> "rather" ------------------------------------------------------------------------------ @ B.5 c 23 23 Sect B.5.8.2 EDITORIAL COMMENT. page 122, line 786: Problem: Typo - a reference to ISO/IEC 9945-1:1990 appears in the middle of the text If ballot number #1 is accepted then this editorial comment is not relevant and can be discarded. Action: Delete "ISO/IEC 9945-1:1990" from this text ------------------------------------------------------------------------------ @ C c 24 24 Sect C COMMENT. page 144, line 79: Problem: (Changes to not described.) Some new _PC_* and possibly _SC_* defines have been added to in this draft (but modified by some of my earlier objections), but they don't show up in this annex. Action: Add any new _SC_* and _PC_* defines that remain in the next draft to the list of changes to this annex. ------------------------------------------------------------------------------ ============= End of X/Open ( The Open Group) Institutional Ballot =========== ----- Andrew Josey The Open Group Base WG Chair Apex Plaza,Forbury Road, Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group.