From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Mon, 27 Apr 1998 10:34:06 +0100 Subject: Proposed Vote on Realtime test methods hi All, This is my proposed input to the UK POSIX Panel on the Realtime test methods. If you have any comments please let me know. I don't know whether we can suggest to the US Delegation that they withdraw the work from ISO but that would be an acceptable course thanks Andrew +++++++++++++++++++++++++++++++ Vote on PDAM1 to IS 14515-1 Disapproval of the draft for the following reasons: We have several general concerns against progressing this to the status of an ISO standard. The slow progress of development and the small number of active participants in its development leads to a question of continued market relevance . The development organization should review the progress of this project , assure continued market relevance , consider changes to improve progress and report back to WG15. Unlike IS 14515 this work is not being validated by implementations of test suites. The lack of validation leads to concerns over the accurracy of the final standard. As such until the accurracy of the standard can be assurred we cannot approve this for ISO status. ----- Andrew Josey The Open Group Base WG Chair Email: a.josey@opengroup.org 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. From wg15-uk-request@opengroup.org Mon Apr 27 16:16:09 1998 Received: from postman.opengroup.org [130.105.1.152] by hermes via SMTP (QAA27742); Mon, 27 Apr 1998 16:15:55 +0100 (BST) Received: (qmail 479 invoked by uid 20); 27 Apr 1998 15:08:41 -0000 Resent-Date: 27 Apr 1998 15:08:41 -0000 Resent-Cc: recipient list not shown:;@exeter.ac.uk Message-Id: <9804271508.AA16906@mailgate.rdg.opengroup.org> From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Mon, 27 Apr 1998 16:01:31 +0100 Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: wg15-uk@rdg.opengroup.org Subject: Input for letter ballot N2648 - PDAM5 to IS9945-1 Resent-Message-ID: <"J3u_HC75BbE.A.YJ.59JR1"@postman.opengroup.org> Resent-From: wg15-uk@opengroup.org X-Mailing-List: wg15-uk:archive/latest/1550 X-Loop: wg15-uk@opengroup.org Precedence: list Resent-Sender: wg15-uk-request@opengroup.org Status: RO Nick, All I don't know whether the IEEE ballot for 1003.1A/D14 will address the issues below and so I am submitting a partial copy of the X/Open (The Open Group) ballot for consideration as part of the UK position to the letter ballot on N2648 . I understand that there may be contentious issues here and so am open to a discussion of changes - particularly on the first item , where another option would be to make the fts_*() functions optional under their own feature macro - although the preferred action would be to remove them. Proposed Disposition on PDAM 5 to IS 9945-1: [X] Disapproval of the draft for reasons below: [X] Acceptance of these reasons and appropriate changes in the text will change our vote to approval regards Andrew +++++++++++++++++++++++++++++++++++++++++++++++++ @ 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. ------------------------------------------------------------------------------ @ 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. ------------------------------------------------------------------------------ @ 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} ------------------------------------------------------------------------------ @ 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]" ------------------------------------------------------------------------------ @ 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 ------------------------------------------------------------------------------ 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.