Usenet 1993 July/InfoMagic USENET CD-ROM July 1993.ISO/sources/std_unix/USENIX.ballot

Text File | 1988-01-06 | 50.7 KB | 2,296 lines

                                                  John S. Quarterman
                                        Institutional Representative
                                                        512-320-9031
                                                    uunet!usenix!jsq
                                                 [e-mail]

                         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
                                                 [e-mail]

              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 $