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.