Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.15/text0026.txt

Text File | 1989-01-17 | 7.4 KB | 185 lines

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]



      An update on UNIX|= Standards Activities - Part 2

                    C Language Standard

                     November 18, 1988

           Shane P. McCarron, NAPS International

C Language Standard

X3J11 (ANSI C standardization committee) met 26-30 Sep. 1988
at Sunnyvale, CA.  Principal business of the meeting was to
respond to comments received during the third round of
formal public review, which had closed earlier that month.
In addition to the 15 letters formally registered with
CBEMA's X3 Secretariat, 27 unregistered letters were
included.  There were 632 items contained in these 42
letters.  In order to address them all, the committee was
divided into response preparation subgroups, each of which
tackled a subset of the total list of items.  From time to
time, the whole committee reassembled to hear issues that
the subgroups were not able to completely resolve by
themselves.  In several cases a straw vote was taken to
determine the sense of the committee. The resulting
responses were formatted to produce the official X3J11
Response Document.

At the Sunnyvale meeting, several editorial changes to the
draft standard were approved. The working definition of
``editorial'' was:  A change is editorial if it clarifies
the original intent of the committee; it is substantive if
it changes the committee's intent.

There were several issues that were of particular interest
to the UNIX/POSIX community:

   o+ A change was made that clarified the ability of an
     application to portably reestablish a signal handler
     for the signal that caused entry to the handler.  This
     is indeed allowed under the standard.  The important
     passage reads:

          If the signal occurs other than as a result of
          calling the abort or raise function, the behavior

__________

  |= UNIX is a registered trademark of AT&T in the U.S. and
    other countries.


                           - 2 -

          is undefined if the signal handler calls any
          function in the standard library other than the
          signal function itself (with a first argument of
          the signal number corresponding to the signal that
          caused the invocation of the handler) or refers to
          any object with static storage duration other than
          by assigning a value to a static storage duration
          variable of type volatile sig_atomic_t.

   o+ IEEE Std 1003.1-1988 (POSIX) requires that the fflush
     function specified by X3J11 have some additional
     semantics.  The committee confirmed that this was
     indeed allowed by ANSI C.

   o+ The IEEE P1003.1 working group had asked X3J11 to
     consider making the symbol "environ" a reserve external
     identifier.  This would mean that a ANSI C conforming
     portable application could not use the symbol.  This
     request was made because in traditional UNIX
     implementations application launch routines initialize
     this variable to be a pointer to the user's environment
     variable list, and this may not be what a strictly
     conforming ANSI C application would expect.  This issue
     was raised before the committee, but found no support
     for a change; the committee response for this was as
     follows:

          The ANSI C and IEEE 1003.1-1988 standards are not
          necessarily in conflict here, although it is true
          that in order to avoid the name-space conflict a
          mutually conforming implementation must rely on
          some mechanism such as `global symbolic equate' or
          a zero-size global object `environ' in a separate
          library module immediately preceding the module
          that defines storage for `__environ' (the name
          used by the C run-time startup code).  Implementor
          control over the way the linker operates, while
          inappropriate to require for the more universal C
          Standard (hence the constraint on uniqueness of
          external identifiers), is not unrealistic to
          expect for most POSIX implementations.  Several
          implementors have in fact indicated their
          intention to provide such a feature.

          Another solution, of course, would be to use
          separate run-time startup modules for strict
          ANSI-conforming and vendor-extended (possibly
          POSIX-conforming) implementations, perhaps via a
          compiler flag.  This may be useful anyway, for
          hiding extensions in certain standard headers.''


                           - 3 -

Because no substantive changes to the proposed standard
resulted from the third-round review process, X3J11 voted
unanimously to submit the standard as edited to reflect
approved editorial changes to CBEMA X3 as the proposed ANSI
C standard, pending completion of additional review as
described below.

The draft Response Document was reviewed first by a small
group of X3J11 members using electronic mail, then by a
group meeting at Plum-Hall in Cardiff, NJ on 20-21 Oct.
1988.  The responses were checked for completeness,
consistency, and accuracy, and occasionally the original
responses were changed to achieve those goals, or to meet
the additional requirement that no unauthorized substantive
change to the proposed standard could be promised by any
response.  Changes made at the review meeting were
subsequently edited into the master Response Document.  Two
significant areas of the standard were affected by editorial
changes resulting from the response review process: The
description of pointer arithmetic was substantially reworked
to avoid reliance on an assumption of byte addressability,
and the specification of the role of type qualifiers was
rewritten to clarify the significance of what was called the
``top type'' (now called ``type category'').

On 1 Nov. 1988, the draft proposed Standard itself was
reviewed by several X3J11 members in a meeting at Summit,
NJ.  Since the draft already contained the results of the
Sunnyvale meeting and response review meeting, very few
changes were found to be necessary at the draft review
meeting.

On 9 Nov. 1988, the Rationale Document (designed to
accompany the Standard) was reviewed by a group of X3J11
members meeting in Cambridge, MA.

On 14 Nov. 1988, copies of all three documents (Response,
Standard, Rationale) were express-mailed to the 15 X3-
registered commenters, who have 15 working days (from
November 18th) in which to reply to X3 if they feel that
their items were not properly addressed by X3J11.  The
commenters were encouraged to first discuss problems with
X3J11 members, in hopes of reducing the amount of negative
feedback to X3.

On 9 Dec. 1988, all three documents plus any feedback from
the commenters are to be submitted to CBEMA's X3 Secretariat
as the official X3J11 proposal for the ANSI Standard for
Programming Language C.  After review by X3, assuming no
problems arise the proposed Standard will then be submitted
to ANSI for official ratification as an ANSI standard.  It


                           - 4 -

seems probable that the final ANSI C standard will be
published some time during 1989.

The Watchdog contact person in X3J11 is Doug Gwyn.  He can
be reached at:

          Doug Gwyn
          US Army Ballistic Research Lab
          801 L Cashew Ct.
          Belair, MD  21014
          [e-mail]
          [phone]


Volume-Number: Volume 15, Number 37