ahby@bungia.bungia.mn.org (Shane P. McCarron) (12/11/88)
[ 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
gwyn@brl.mil
+1 (301) 287-6647
Volume-Number: Volume 15, Number 37