Path: utzoo!attcan!uunet!longway!std-unix From: ahby@bungia.bungia.mn.org (Shane P. McCarron) Newsgroups: comp.std.unix Subject: Standards Update, Part 2: C Language Standard Message-ID: <269@longway.TIC.COM> Date: 11 Dec 88 00:07:13 GMT Sender: std-unix@longway.TIC.COM Reply-To: Shane P. McCarron Lines: 183 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) [ 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