home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso
/
std_unix
/
USENIX.ballot
< prev
next >
Wrap
Text File
|
1988-01-06
|
52KB
|
2,296 lines
John S. Quarterman
Institutional Representative
512-320-9031
uunet!usenix!jsq
jsq@longway.tic.com
IEEE 1003.1 Nov 1987 Ballot
4 December 1987
with respect to
1003.1 (POSIX) Draft 12 document dated Oct. 1987
To:
Computer Society Secretariat
IEEE Standards Office
345 East 47th St.
New York, NY 10017
I do not approve as a full use standard 1003.1/D12: this
is a _n_e_g_a_t_i_v_e ballot.
With 12 specific objections and 32 non-binding comments
specified in the 35 pages attached.
Signed:
John S. Quarterman
Question on possible objections to alternate proposals for
Section 10:
Yes, I would object if _o_n_l_y the cpio format were required.
No, I would _n_o_t object if _o_n_l_y the Trial Use tar format
were required.
Yes, I would object if this were not included here and
defered for resolution in some future POSIX ballot
(1003.2 or 1003.1).
John S. Quarterman
Institutional Representative
512-320-9031
uunet!usenix!jsq
jsq@longway.tic.com
12 Specific Objections and 32 Non-Binding Comments
Specified on 35 Pages to Accompany
IEEE 1003.1 Nov 1987 Ballot of 30 November 1987
with respect to
1003.1 (POSIX) Draft 12 document dated Oct. 1987
These objections and comments are organized according to
sections of IEEE 1003.1 Draft 12, with text about
appendices following text about the standard proper,
except:
Appendix B, Rationale and Notes, is treated specially.
Text about it is interspersed in section order with that
about the standard proper so that it can be found near
text about corresponding sections of the standard.
However, text about parts of the Rationale that do not
correspond directly to any part of the standard is placed
between text about appendices A and C.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 2 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_1 _o_f _1_2:
Various so-called options are overspecified, e.g.,
_POSIX_LINK_DIR. Many of these seem to be due to 1003.3
input, partly from NBS. The standard should concentrate
more on what an application should interpret an error
return to mean than on under exactly what conditions the
implementation is required to return it. All such options
should be removed from 1003.1 and the corresponding text
in Draft 12 replaced with that of Draft 11.
Here is a list of such options:
_POSIX_PATHNAME_NULL: Make this behavior implementation
defined.
_POSIX_LINK_DIR: Ordinary users should not be allowed to
link or unlink directories. Given mkdir(),
rmdir(), and rename(), there is no need for an
alternative.
_POSIX_UTIME_OWNER: Make this behavior implementation
defined.
_POSIX_GROUP_PARENT: Although this feature can be
implemented regardless of the value of
NGROUPS_MAX, supplementary groups are much less
useful if a new file is created with the creating
process's effective group ID rather than that of
the parent directory. Imagine a file system
subtree containing a set of sources which are
accessible to several people because all of the
files and directories are in a specific group and
all of the appropriate users have that group as
one of theirs. Those users may have different
effective group IDs, because they may have
different primary jobs. Thus new files would be
created in different groups by different users, if
the group of a new file were taken from the
effective group ID. This would make some new
files inaccessible to some of the users who are
supposed to have access to them, unless all users
remembered to change the group of each new file to
match its parent directory.
So _POSIX_GROUP_PARENT should not be a separate
option: if supplementary groups are present (as
determined by NGROUPS_MAX), a new file must be
created in the group of its parent directory.
_POSIX_CHOWN_SUP_GRP: Standard behavior should be as if
this were defined: with NGROUPS_MAX greater than
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 3 of 35
zero, it is a basic part of the supplementary
groups facility. But this should not be an
option: 1003.1 should specify this behavior
directly.
_POSIX_KILL_SAVED: Having this defined would require many
existing systems to change. On the other hand, it
is not really a separate option, but is a part of
the saved user ID feature. This ``option'' should
be bundled back into _POSIX_SAVED_IDS.
_POSIX_KILL_PID_NEG1: Applications can easily include code
that will handle either behavior, without needing
to check an option. 1003.1 should remove the
explicit option and change the wording back to
implementation defined.
_POSIX_PGID_CLEAR As long as process groups still in use
aren't reused, this one shouldn't matter. It's
implementation defined behavior, and should be
left as such, not as an option.
_POSIX_DIR_DOTS: After mkdir(), a directory should contain
dot and dot-dot, rmdir() should be able to remove
such a directory, and 1003.1 should say so.
Beyond that, why does this matter? Another non-
option. Remove it.
_POSIX_EXIT_SIGHUP: Some existing systems do this (System
V); some don't (4.3BSD). If exit() causes SIGHUP
to be sent, processes that don't want to get
SIGHUP should set the action for it to SIG_IGN, as
long as it only happens for session process
groups, not for job control process groups.
Specify the behavior directly in 1003.1 (as no
SIGHUP being sent) or leave it implementation-
defined, but get rid of the option.
_POSIX_V_DISABLE: Disabling individual special characters
should always be possible. Require this in the
standard and remove the option.
_POSIX_NO_TRUNC: This is a nice feature, but doesn't
reflect any existing system, and so is by
definition non-standard. Making it
implementation-defined makes sense, due to its
desirability. Requiring it does not.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 4 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_2 _o_f _1_2:
The standard should require all optional functions, such
as getgroups(), to have at least stubs in all
implementations, regardless of whether the actual facility
is implemented or not. This is to allow applications that
determine at run time whether the facility is present:
without the stubs, such applications could not be compiled
for implementations where the facility is not present.
Here is a list of such functions:
_g_e_t_g_r_o_u_p_s(), _j_c_s_e_t_p_g_r_p(), _t_c_s_e_t_p_g_r_p(), _w_a_i_t_2().
The requirement can be done either in the text about each
function, or in Conformance sS2.2.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 5 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_3 _o_f _1_2:
sS0.0 Foreword, pronunciation footnote, p 3, l 29+:
No consensus was reached on this pronunciation in any
Working Group meeting according to the process described
in B.1.2.10. Although the Foreword is not a part of the
standard proper, it should not contain misinformation:
this footnote should be removed.
sSB.1 Introduction, p 182, l 31-34:
This paragraph is inaccurate and inappropriate. I've
never heard anyone pronounce POSIX as in the second
variant in the first sentence, and the first variant,
while recognizable as a common pronunciation, is not
universal. The assertion that the Working Group is
attempting to promulgate a standardized pronunciation is
untrue: there is no such consensus.
The Working Group has no business attempting to
standardize pronunciations, especially for a standard that
it hopes will gain international acceptance. For example,
the usual European pronunciation is neither of the ones
given. The Working Group should concentrate on
standardizing an operating system interface, not on
creating shibboleths.
The indicated lines should be removed.
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_4 _o_f _1_2:
sS0.0 Foreword, p 7, l 122-128:
The Steering Committee list is incomplete, since it does
not include the Institutional Representatives, among
others. The list should be completed, using information
obtained from Jim Isaak, the chair.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1 _o_f _3_2:
sSB.1.2.10 IEEE Consensus Process, p 186, l 165-166:
These Institutional Representatives also served on
the Working Group, but participated there as
individuals.
In what sense is this true? All three repeatedly voiced
the position of their organizations. The final five words
of the quoted sentence should be removed.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 6 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2 _o_f _3_2:
sS1.0 Scope, p 18, l 29:
program can be compiled to execute on
Shouldn't ``translated'' be used instead of ``compiled''
since that has been done elsewhere to be consistent with
the usage of X3J11, i.e., in order to avoid ruling out the
possibility of the use of an interpretor instead of a
compilor?
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 7 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_5 _o_f _1_2:
sSB.2.2 Conformance, p 197, l 574-591:
sS2.2 Conformance, p 20-22, l 26-110:
This Rationale section needs to be rewritten to reflect
changes in organization in the corresponding section in
the standard proper. As it is, the rationale text
confuses the meaning of the standard: thus the objection.
The changes mostly involve moving text into subsections:
sSB.2.2 Conformance, p 197, l 574:
Change
The definition of conforming implementations sS2.2.1
allows
to
These definitions allow
sSB.2.2 Conformance, p 197, l 574-580:
Move both paragraphs on implementation conformance (after
making the above change) to the beginning of B.2.2.1,
Implementation Conformance.
sSB.2.2 Conformance, p 197, l 581-582:
Change
The definitions of a Conforming Application Using
Extensions sSB.2.2.2 and of a Strictly Conforming
Application sSB.2.2.3
to
These definitions
sSB.2.2 Conformance, p 197, l 581-585:
Move the paragraph (after making the above change) to the
beginning of B.2.2.2, Application Conformance.
sSB.2.2 Conformance, p 197, l 586:
Change
These three conformance definitions
to
These conformance definitions
sSB.2.2 Conformance, p 197, l 588:
Change
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 8 of 35
respectively, of the Trial Use Standard
to
of the Trial Use Standard
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 9 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_3 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.2.2.3.1 C Language Binding, p 200, l 677-678:
Change
Then, in <stdlib.h>, there would be the following:
to
Then, in <stdlib.h>, there could be the following:
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_4 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.2.2.3.1 C Language Binding, p 200, l 681:
Change
implementor would also is required
to
implementor would also be required
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 10 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_6 _o_f _1_2:
sS2.3 General Terms, Job Control Option, p 25, l 232-241:
The saved set user ID option isn't stigmatized in this
manner in sS2.3, nor is any other option. This singling
out of this particular option gives the impression that it
is in some way less recommended than other options.
Change the paragraph label from
Job Control Option
to
job control
sS2.3 General Terms, job control process group leader, p 26, l 248:
Change
Job Control Option
to
job control
Reasons as for
sS2.3 General Terms, Job Control Option, p 25, l 232-241:
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 11 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_5 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.2.3 General Terms, hosted implementation, p 202, l 785:
Change
mknode()
to
mknod()
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_6 _o_f _3_2:
sSB.2.3 General Terms, open file description, p 203, l 813-820:
...and file access information.
Append this sentence:
Some historical implementations use the term ``file
table entry.''
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_7 _o_f _3_2:
sSB.2.3 General Terms, open file description, p 203, l 818:
open file description
This is a duplicate of line 813, and should be removed.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_8 _o_f _3_2:
sSB.2.3 General Terms, file descriptor, p 203, l 821-822:
This entry is out of order, and should be put in
alphabetical order between ``file classes'' and ``file
system.'' Also, insert after the paragraph tag on line
821 and before the existing text on line 822:
The following alternate names were discussed:
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 12 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_9 _o_f _3_2:
sSB.2.4 General Concepts, filename portability, p 207, l 944-946:
Otherwise, a portable application would have to
assume that case folding would occur when it wasn't
wanted, but that it wouldn't occur when it was
wanted.
The quoted sentence is hard to interpret, but doesn't seem
to add anything to the already lengthy discussion. Remove
the sentence.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 13 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_7 _o_f _1_2:
sS2.3 General Terms, p 22-29, l 123-375:
There is a general problem with the following definitions:
background process, p 22, l 123-125
controlling process, p 23, l 137-139
controlling terminal, p 23, l 140-144
foreground process, p 25, l 223-225
job control process group leader, p 25, l 242-245
(process ID, p 27, l 309-315)
process group, p 27, l 316-319
process group ID, p 27, l 320-321
process group leader, p 28, l 322-329
session process group leader, p 29, l 364-375
These are all closely related entities, and the attempt to
describe them separately loses important aspects of their
interrelations.
For example, the definitions of foreground and background
processes don't refer to one another (except indirectly
through 7.1.1.5), so without a priori knowledge or reading
the entire set of definitions, one cannot know that they
are opposites. None of the definitions of the various
kinds of process groups mentions the word signal, and it
is only the definition of a controlling terminal that says
what a process group is *for*: determining what processes
receive signals caused by input at a terminal. But the
definition of controlling terminal is not referenced in
the definition of process group.
The entries are inconsistent: while there are definitions
for both process group and process group leader, there are
definitions of session process group leader and job
control process group leader without corresponding
definitions of session process group or job control
process group.
The standard talks about job control, but never says what
a job is (in 2.3 General Terms: 7.1.1.3 Process Groups
defines ``job'' as a synonym for ``process group;'' but
neither of the definitions for Job Control Option or job
control process group leader in 2.3 refer to 7.1.1.3).
Is ``job'' not a short synonym for the set of processes in
a job control process group? Does the term ``process
group'' refer to just the integer or also to the set of
processes that have that integer as their process group?
Perhaps the terms ``session'' and ``job'' should be used
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 14 of 35
to refer to the sets of processes corresponding to a
session process group and a job control process group,
respectively?
Are all of the functions of a process group leader:
1. to produce (by fork()) new processes in the same
process group,
2. in the case of a session process group leader, to
cause SIGHUP to be sent to the process group on exit
of the leader,
3. in the case of a session process group leader, to
set the process group of the controlling terminal to
zero?
There are at least five major interrelated entities here:
processes, process groups, process group leaders, and
controlling terminals. Important questions regarding the
mappings among them are left unanswered. For examples:
Can a process be in more than one process group? Can a
controlling terminal simultaneously control more than one
process group? Can a process be a process group leader of
more than one process group? How does a process change
between foreground and background (by changing its process
group or its controlling terminal, and does the process
perform the change itself, or does something else do it
for it)? How is process group zero distinguished?
Some of these questions can be answered by careful reading
of the existing definitions. Others (such as the first,
most basic one) are left unspecified by vague language.
Some are only clarified by rationale wording in B.3.3.
In this situation, differing interpretations, and thus
differing implementations, are practically guaranteed.
This is the kind of problem that 2.4 General Concepts is
there for. Managing the trees of related processes that
process groups represent is analogous to managing the
trees of related files that file systems represent. There
should be an entry in General Concepts for process group,
analogous to the existing entries for file access
permissions, file hierarchy, and pathname resolution. The
process group entry should also contain references to the
appropriate sections of the standard for related functions
such as setpgrp(), jcsetpgrp(), and tcsetpgrp().
The existing definitions in 2.3 General Terms (listed
above) should be removed or reduced to stubs that point at
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 15 of 35
the process group entry in 2.4 General Concepts.
Replacement text will be supplied in a ballot from Fred
Clegg of Hewlett Packard.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 16 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_8 _o_f _1_2:
sS3.2.2.2 Description (wait()), p 56, l :
Include _w_a_i_t_p_i_d() from Appendix E, for the reasons given
in Appendix E.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_0 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sS3.2.2.2 Description (wait()), p 56, l 301:
Change
the the process group ID
to
then the process group ID
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 17 of 35
sS4. Process Environment, p 73-86, l 1-412:
No comments and no objections about this section.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 18 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_1 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.5.2.2 Working Directory Pathname, p 236, l 2005:
Change
priveleged
to
privileged
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_2 _o_f _3_2:
sSB.5.2.2 Working Directory Pathname, p 236, l 2005:
The error being discussed isn't named. Change:
Including this error
to
Including the error [EACCES]
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_3 _o_f _3_2:
sSB.5.2.2 Working Directory Pathname, p 236, l 2007:
Change
beyond his control. (The other two failures should
not be beyond his control.)
to
beyond the control of the application writer or the
user.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_4 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.5.2.2 Working Directory Pathname, p 236, l 2008-2009:
pwd()
This is a program or process, not a function: remove the
parentheses and use bold face, not italics.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 19 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_5 _o_f _3_2:
sSB.6 Input and Output Primitives, O_NONBLOCK, p 241, l 2203:
The overall semantics are that it applies only to a
file descriptor.
This is easy to misinterpret as meaning
...applies only to a file descriptor, not to a
socket descriptor.
Change to:
The overall semantics are that it applies only to a
single file descriptor, not to all file descriptors
for the file.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_6 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.6 Input and Output Primitives, O_NONBLOCK, p 241, l 2206:
Change
The problem with the 1984 /usr/group Standard that it
does not
to supply the missing verb:
The problem with the 1984 /usr/group Standard is that
it does not
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_7 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.6.1 Pipes, p 242, l 2237:
Missing period. Change
[EBADF]
to
[EBADF].
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 20 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_9 _o_f _1_2:
sS6.4.1.3 read() Returns, p 123, l 123:
Remove [SIGINTR] error, i.e., require an interrupted read
to return the amount read.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_8 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.6.4.2 Write to a File, p 245, l 2327-2329:
The change bars are wrong for the write request example:
should be C, not A.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_1_9 _o_f _3_2:
sSB.6.4.2 Write to a File, p 246, l 2372-2373:
The rationale text didn't get updated to reflect the
decision (made in the September 1987 meeting in Nashua New
Hampshire) to require partial writes on pipes or FIFOs
with O_NONBLOCK set. Change:
There is no way provided for an application to
determine whether the implementation will ever
perform partial writes to a pipe or FIFO.
to
The Working Group decided not to make an exception
regarding partial writes when O_NONBLOCK is set:
therefore a standard interface implementation is
required to perform them. However, the standard does
not specify exactly when a partial write will be
performed, because that would require specifying
internal details of the implementation.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_0 _o_f _3_2:
sSB.6.5.1 Data Definitions for File Control Operations, p 247, l 2403:
different file pointers
Shouldn't this be
different file offsets
in order to be consistent with usage elsewhere in the
standard and Rationale (e.g., 6.5.3, l 133-134, or
B.6.4.2, p 247, l 2390), and to avoid confusion with
X3.159 file pointers?
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 21 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_1 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.7 Device- and Class-Specific Functions, p 252, l 2586:
Change
Europeon
to
European
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_2 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sS7.1.1.6 Input Processing and Reading Characters, p 137, l 80:
Change
shall shall
to
shall
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_3 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sS7.1.1.7 Canonical Mode Input Processing, p 138, l 98:
Change
See the Special Characters sS7.1.1.1
to
See Special Characters sS7.1.1.1
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 22 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_1_0 _o_f _1_2:
sS8.1.1 Extensions to asctime() Function, p 156-158, l 44-114:
sSB.8.1.1 Extensions to asctime() Function, p 256-257, l 10-67:
The subject of the format of the TZ environment variable
has been discussed extensively in previous Working Group
documents and meetings: <86.04 RFC.001>, <86.04 RFC.002>,
<86.04 P.046>, <86.04 D7.A.3>, <86.04 M.015 2. Pg.8>,
<86.09 P.055>, <86.10 C.038>, <86.12 RFC.024>, and <86.12
C.056>. The entire subject was referred to the ANSI X3J11
Working Group <87.01 N.001 6.6 Pg.17>. It is true that
they have since declined to accept it.
However, there is a de facto standard in use world wide
for this problem: that proposed in RFC.001 and P.055. It
takes into account every known problem with time zones
except solar time. It was developed over many months by a
group spanning three continents. It is implemented on and
used with a large number of system interface
implementations.
There is no indication that the TZ format in Draft 12 has
been as carefully developed as the de facto standard.
B.8.1.1 mentions assumptions, such as that few programs
actually require historical time accuracy (B.8.1.1, p 257,
l 55-58), but does not support those assumptions.
Difficult problems such as U.S. west coast Presidential
election time (a shift of several hours for one day in
November 1988) are not mentioned. 4.2BSD implementations
are mentioned without any mention of 4.3BSD, or awareness
that UCB CSRG has adopted the format of P.055 for future
releases. B.8.1.1 isn't even in appropriate format for
the Rationale: it is still a proposal, with wording
including
sSB.8.1.1 ``This proposal extends'', p 257, l 36:
and
sSB.8.1.1, ``The proposal accommodates'', p 257, l 41:
Section 8.1.1 of Draft 12 is not based on the de facto standard.
Any text for 8.1.1 should be based on the de facto standard.
Section 8.1.1 (and B.8.1.1) should be deleted.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 23 of 35
sS9 System Databases, p 165-168, l 1-97:
No comments and no objections about this section.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 24 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_1_1 _o_f _1_2:
sS10.1 Archive/Interchange File Format, p 169-173, l 1-122:
Objections to this section continue from here until a line
containing only
End of Archive/Interchange Format Specific Objection #11.
Unlike other parts of this ballot, text corresponding to
specific sections of Draft 12 should not be separated out
and viewed independently: the whole set of objections on
this topic should be read together.
There are serious problems with section 10.1 of Draft 12.
Draft 12 should not be accepted as a standard because of
them.
sS10.1 Archive/Interchange File Format, p 169-173, l 1-122:
sSD Alternative Archive/Data Interchange Format, p 285-289, l 1-162:
sSB.10.1 Archive/Interchange File Format, p 262-267, l 208-417:
These sections were put in Draft 12 incorrectly by the
technical editor and do not correspond to the decision of
the Working Group at the September, 1987 meeting in
Nashua, New Hampshire. USTAR format was mistakenly put in
an appendix, rather than remaining in sS10.1.1, as in Draft
11. To restore sections to their appropriate places, move
them like this:
D.1 Extended tar Format -> 10.1.1
10.1.1 cpio Archive Format -> 10.1.2
10.1.2 Multiple Volumes -> 10.1.3
B.10.1.1 cpio Archive Format -> B.10.1.2
B.10.1.2 Multiple Volumes -> B.10.1.3
B.10.1.3 Extended tar Format, p 267, l 390-391: Remove.
B.10.1.3 Extended tar Format -> B.10.1.1
D Alternative Archive/Data Interchange Format, p 285, l 1-5:
Delete this single remaining paragraph of Appendix D.
Also, note the format of the names for the tar and cpio
sections do not agree, in particular the cpio section name
implies that
1. the format is only used for archives and
2. it is not extended.
Neither of these things are true.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 25 of 35
Fix this by the following changes:
10.1.2 cpio Archive Format -> 10.1.2 Extended cpio Format
B.10.1.2 cpio Archive Format -> B.10.1.2 Extended cpio Format
These changes are necessary merely to restore Draft 12 to
the state agreed upon by the Working Group. There is one
more change necessary for that; one that is not so readily
made. It is the first of several specific problems with
the cpio format, enumerated below:
1. file types reserved for implementors
The Working Group agreed that the cpio format would
be modified to reserve a range of file types for use
by implementors, as is already done in D.1 Extended
tar Format, p 289, l 151-153:
ASCII letters 'A' through 'Z' are reserved for custom implementations.
All other values are reserved for specification in future
revisions of the standard.
That text for the cpio section was to be supplied by
the proposers of the cpio format, but has not been.
2. symbolic names for reserved values
sS10.1.1.5 cpio Values, p 172, l 106-108:
There are no symbolic names given for the three
reserved values in the standard. Names are given in
the Rationale (B.10.1.1.5, pages 264,265, l
301,305,311), but are merely ``suggested'' even
there. They should be given in the standard, as for
SYMTYPE and CONTTYPE for USTAR (D.1, p 286, l
49,54). Although the meaning and use of such
reserved types cannot be given in the standard (only
in the Rationale), the standard should reserve
actual symbolic names for the reserved types in
order to facilitate programming of the required
format-creating and format-reading utilities.
3. link resolution problems caused by _c__i_n_o field size
The _c__i_n_o field of the cpio format is derived from
the UNIX inode number. Many implementations of cpio
use only 16 bits for this number, and thus cannot
properly resolve links noted in cpio archives that
use more bits for this number. Tar and USTAR
formats do not have this problem, because they do
not use a number like this to resolve links. While
some USTAR file types cannot be read by historical
tar implementations, an error will usually be
produced. This cpio problem will cause silent
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 26 of 35
creation of erroneous links, which is worse.
4. implementations, extensions, and availability
There is a public domain implementation of USTAR
format that has been widely distributed. The tar
program, which writes archives readable by that
public domain implementation, exists on all known
UNIX systems. The cpio program exists on only some
UNIX systems, and there is no public domain
implementation. To be be practical for use for
archiving and data interchange among many existing
systems, such as those with symbolic links, the
existing cpio program is inadequate, and an improved
program incorporating the extensions of Draft 12
would be necessary: there is no such publicly
available extended cpio program.
5. completeness and future extensions of specification
USTAR format, as in Draft 12 Appendix D, represents
years of careful thought and effort on the part of
the Working Group and others. The Working Group has
repeatedly requested the proponents of the extended
cpio format to upgrade it to the level of the USTAR
format. The proponents have repeatedly failed to do
so when first requested, as witness the problems
listed above that remain in Draft 12, and the lack
of Rationale in Draft 11. The extended cpio format
in Draft 12 is technically inferior to the USTAR
format, and it is not clear whether its deficiencies
will or can be corrected, nor that any necessary
future extensions will be made in a timely manner.
6. common practice for software distributions
Most vendors of UNIX systems distribute software in
tar format. Adding or converting to distributions
in cpio format would be an unnecessary and expensive
burden to require them to carry.
The extended cpio format, in Draft 12 as section 10.1.1
(and B.10.1.1), should be entirely removed, leaving only
the superior USTAR format.
Minimal changes from Draft 12 to accomplish this are as
follows:
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 27 of 35
D.1 Extended tar Format -> 10.1.1
10.1.1 cpio Archive Format -> Delete
10.1.2 Multiple Volumes -> 10.1.2
B.10.1.1 cpio Archive Format -> Delete
B.10.1.2 Multiple Volumes -> B.10.1.2
B.10.1.3 Extended tar Format, p 267, l 390-391: Remove.
B.10.1.3 Extended tar Format -> B.10.1.1
D Alternative Archive/Data Interchange Format, p 285, l 1-5:
Delete this single remaining paragraph of Appendix D.
See also the comment below about:
sSB.1.3.3, Specific Derivations, p 190, l 318-322:
End of Archive/Interchange Format Specific Objection #11.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 28 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_4 _o_f _3_2:
sSA.2.1 C Language Standard, p 176, l 30-43:
sSA.3 Industry Open Systems Publications, p 180, l 142-150:
These subsections duplicate information in Appendix B in,
respectively:
sSB.11.1 Related Standards, p 268, l 432-440:
sSB.11.1 Related Standards, p 268-269, l 441-452:
B.11.1 is a better place for this material, since it is
arranged there to correspond with the descriptions of the
relations of the standards in
sSB.1.3.1 Related Standards and Documents, p 188, l 226-243:
The access information in B.11.1 for these two documents
is also more complete than that in Appendix A.
The two subsections of Appendix A cited above should be
removed.
sSA.2 Standards Closely Related to the 1003.1 Document, p 176, l 29:
Add the following text at the beginning of this
subsection:
For a description of the standards from which IEEE
Std 1003.1 was most immediately derived, see B.1.3.1,
and for availability of those documents, see B.11.1.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 29 of 35
sSB. Rationale and Notes, p 181-271, l all:
Comments and Objections to Appendix B are interspersed
with those to the Standard proper, in the order of
sections of the standard. Exceptions are general changes
to the Rationale, parts of B.1 that do not correspond
directly to any part of the standard, and B.11, none of
which corresponds to the standard directly. Materials on
those areas appear here.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_5 _o_f _3_2:
Replace all occurrences of `Version 8' and `Version 9'
with, respectively, `Eighth Edition' and `Ninth Edition'
since the latter are the names preferred by the Bell Labs
Research Group. The occurences are in:
sSB.1.3.2 Historical Implementations, p 189, l 259:
sSB.2.3 General Terms, p 200, l 693:
sSB.3.2.1 Wait for Process Termination, p 219, l 1387:
sSB.6.4 Input and Output, p 244, l 2291:
sSB.6.4.2 Write to a File, p 246, l 2383:
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_6 _o_f _3_2:
sSB.1.3.1, Related Standards and Documents, p 188, l 242-3:
there has been a representative of SIGMA at most
recent P1003.1 Working Group meetings.
To be more accurate, change
at most recent
to
at some
because there have been recent meetings without SIGMA
representatives.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 30 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_7 _o_f _3_2:
sSB.1.3.3, Specific Derivations, p 190, l 318-322:
Change to read:
data archive/interchange format
The Extended tar Format, section 10.1.1, is derived
from the tar program used in Version 7 and 4.3BSD,
and provided with System V. The precise format in
the Full Use Standard has evolved incrementally from
that in earlier drafts of POSIX. The cpio format,
section 10.1.2, is derived from that of System V.
See Specific Objection #11, on page 24 above, about:
sS10.1 Archive/Interchange File Format, p 169-173, l 1-122:
Remove the last sentence of the above new text when cpio
format is deleted from the standard.
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_8 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.1.4 C Language, X3J11, and P1003.1, p 191, l 341-342:
Change
operating-system specific
to be
operating system-specific
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_2_9 _o_f _3_2:
sSB.1.4 C Language, X3J11, and P1003.1, p 192, l 392:
After
Kernighan and Ritchie
append
(see sSB.11.1)
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 31 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_3_0 _o_f _3_2 (_T_y_p_o_g_r_a_p_h_i_c_a_l _E_r_r_o_r):
sSB.1.4.5, Base by X3J11, Additions by P1003.1, p 193, l 436:
The function getenv()4.6.1
Add missing space and section sign after the parentheses.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 32 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_3_1 _o_f _3_2:
sSB.11.2 Historical Implementations, p 269, l 474-476:
Imprecise reference: change
USENIX Association Conference Proceedings
to
Winter 1987 USENIX Association Conference
Proceedings, Washington, D.C.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 33 of 35
_S_p_e_c_i_f_i_c _O_b_j_e_c_t_i_o_n #_1_2 _o_f _1_2:
sSC. Comparison to System V Interface Definition, p 273-284, l 1-297:
Appendix C was useful to the Working Group during the
composition of drafts of the standard. However, it is not
appropriate for the Full Use Standard, because it puts
undue emphasis on only one of the major historical
implementations whose documentation was used as base
documents for the standard; see:
sS0 Foreword, Base Documents, p 4, l 40-45:
sSB.1.3.2 Historical Implementations, p 188-189, l 244-273:
If this sort of comparison appendix is to be included,
there should at least be another one for the other current
historical implementation of this type, 4.3BSD. Since no
such new appendix is currently available, Appendix C
should be deleted.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 34 of 35
sSD. Alternative Archive/Data Interchange Format, p 285-289, l 1-162:
See Specific Objection #11, on page 24 above, about:
sS10.1 Archive/Interchange File Format, p 169-173, l 1-122:
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 35 of 35
_N_o_n-_b_i_n_d_i_n_g _C_o_m_m_e_n_t #_3_2 _o_f _3_2:
sSE. Alternative wait() Functions, p 291-294, l 1-108:
See Specific Objection #8 about sS3.2.2.2.
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
USENIX Association 1003.1 D12 Response Page 36 of 35
Total Accompanying Pages: .nr tP 35
Total Specific Objections: .nr tO 12
Total Non-Binding Comments: .nr tC 32
Total Typographical Errors: .nr tT 14
$Revision: 3.1 $ $Date: 87/12/04 18:36:49 $
