home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / csu.shar / 33 < prev    next >
Internet Message Format  |  1988-12-19  |  8KB

  1. Path: longway!std-unix
  2. From: ahby@bungia.bungia.mn.org (Shane P. McCarron)
  3. Newsgroups: comp.std.unix
  4. Subject: Standards Update, Part 2:  C Language Standard
  5. Message-ID: <269@longway.TIC.COM>
  6. Date: 11 Dec 88 00:07:13 GMT
  7. Sender: std-unix@longway.TIC.COM
  8. Reply-To: Shane P. McCarron <ahby@bungia.bungia.mn.org>
  9. Lines: 183
  10. Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)
  11.  
  12. [ These Standards Updates are published after each IEEE 1003
  13. meeting, and are commissioned by the USENIX Association.
  14. See Part 1 for contact information.  -mod ]
  15.  
  16.  
  17.  
  18.       An update on UNIX|= Standards Activities - Part 2
  19.  
  20.                     C Language Standard
  21.  
  22.                      November 18, 1988
  23.  
  24.            Shane P. McCarron, NAPS International
  25.  
  26. C Language Standard
  27.  
  28. X3J11 (ANSI C standardization committee) met 26-30 Sep. 1988
  29. at Sunnyvale, CA.  Principal business of the meeting was to
  30. respond to comments received during the third round of
  31. formal public review, which had closed earlier that month.
  32. In addition to the 15 letters formally registered with
  33. CBEMA's X3 Secretariat, 27 unregistered letters were
  34. included.  There were 632 items contained in these 42
  35. letters.  In order to address them all, the committee was
  36. divided into response preparation subgroups, each of which
  37. tackled a subset of the total list of items.  From time to
  38. time, the whole committee reassembled to hear issues that
  39. the subgroups were not able to completely resolve by
  40. themselves.  In several cases a straw vote was taken to
  41. determine the sense of the committee. The resulting
  42. responses were formatted to produce the official X3J11
  43. Response Document.
  44.  
  45. At the Sunnyvale meeting, several editorial changes to the
  46. draft standard were approved. The working definition of
  47. ``editorial'' was:  A change is editorial if it clarifies
  48. the original intent of the committee; it is substantive if
  49. it changes the committee's intent.
  50.  
  51. There were several issues that were of particular interest
  52. to the UNIX/POSIX community:
  53.  
  54.    o+ A change was made that clarified the ability of an
  55.      application to portably reestablish a signal handler
  56.      for the signal that caused entry to the handler.  This
  57.      is indeed allowed under the standard.  The important
  58.      passage reads:
  59.  
  60.           If the signal occurs other than as a result of
  61.           calling the abort or raise function, the behavior
  62.  
  63. __________
  64.  
  65.   |= UNIX is a registered trademark of AT&T in the U.S. and
  66.     other countries.
  67.  
  68.  
  69.                            - 2 -
  70.  
  71.           is undefined if the signal handler calls any
  72.           function in the standard library other than the
  73.           signal function itself (with a first argument of
  74.           the signal number corresponding to the signal that
  75.           caused the invocation of the handler) or refers to
  76.           any object with static storage duration other than
  77.           by assigning a value to a static storage duration
  78.           variable of type volatile sig_atomic_t.
  79.  
  80.    o+ IEEE Std 1003.1-1988 (POSIX) requires that the fflush
  81.      function specified by X3J11 have some additional
  82.      semantics.  The committee confirmed that this was
  83.      indeed allowed by ANSI C.
  84.  
  85.    o+ The IEEE P1003.1 working group had asked X3J11 to
  86.      consider making the symbol "environ" a reserve external
  87.      identifier.  This would mean that a ANSI C conforming
  88.      portable application could not use the symbol.  This
  89.      request was made because in traditional UNIX
  90.      implementations application launch routines initialize
  91.      this variable to be a pointer to the user's environment
  92.      variable list, and this may not be what a strictly
  93.      conforming ANSI C application would expect.  This issue
  94.      was raised before the committee, but found no support
  95.      for a change; the committee response for this was as
  96.      follows:
  97.  
  98.           The ANSI C and IEEE 1003.1-1988 standards are not
  99.           necessarily in conflict here, although it is true
  100.           that in order to avoid the name-space conflict a
  101.           mutually conforming implementation must rely on
  102.           some mechanism such as `global symbolic equate' or
  103.           a zero-size global object `environ' in a separate
  104.           library module immediately preceding the module
  105.           that defines storage for `__environ' (the name
  106.           used by the C run-time startup code).  Implementor
  107.           control over the way the linker operates, while
  108.           inappropriate to require for the more universal C
  109.           Standard (hence the constraint on uniqueness of
  110.           external identifiers), is not unrealistic to
  111.           expect for most POSIX implementations.  Several
  112.           implementors have in fact indicated their
  113.           intention to provide such a feature.
  114.  
  115.           Another solution, of course, would be to use
  116.           separate run-time startup modules for strict
  117.           ANSI-conforming and vendor-extended (possibly
  118.           POSIX-conforming) implementations, perhaps via a
  119.           compiler flag.  This may be useful anyway, for
  120.           hiding extensions in certain standard headers.''
  121.  
  122.  
  123.                            - 3 -
  124.  
  125. Because no substantive changes to the proposed standard
  126. resulted from the third-round review process, X3J11 voted
  127. unanimously to submit the standard as edited to reflect
  128. approved editorial changes to CBEMA X3 as the proposed ANSI
  129. C standard, pending completion of additional review as
  130. described below.
  131.  
  132. The draft Response Document was reviewed first by a small
  133. group of X3J11 members using electronic mail, then by a
  134. group meeting at Plum-Hall in Cardiff, NJ on 20-21 Oct.
  135. 1988.  The responses were checked for completeness,
  136. consistency, and accuracy, and occasionally the original
  137. responses were changed to achieve those goals, or to meet
  138. the additional requirement that no unauthorized substantive
  139. change to the proposed standard could be promised by any
  140. response.  Changes made at the review meeting were
  141. subsequently edited into the master Response Document.  Two
  142. significant areas of the standard were affected by editorial
  143. changes resulting from the response review process: The
  144. description of pointer arithmetic was substantially reworked
  145. to avoid reliance on an assumption of byte addressability,
  146. and the specification of the role of type qualifiers was
  147. rewritten to clarify the significance of what was called the
  148. ``top type'' (now called ``type category'').
  149.  
  150. On 1 Nov. 1988, the draft proposed Standard itself was
  151. reviewed by several X3J11 members in a meeting at Summit,
  152. NJ.  Since the draft already contained the results of the
  153. Sunnyvale meeting and response review meeting, very few
  154. changes were found to be necessary at the draft review
  155. meeting.
  156.  
  157. On 9 Nov. 1988, the Rationale Document (designed to
  158. accompany the Standard) was reviewed by a group of X3J11
  159. members meeting in Cambridge, MA.
  160.  
  161. On 14 Nov. 1988, copies of all three documents (Response,
  162. Standard, Rationale) were express-mailed to the 15 X3-
  163. registered commenters, who have 15 working days (from
  164. November 18th) in which to reply to X3 if they feel that
  165. their items were not properly addressed by X3J11.  The
  166. commenters were encouraged to first discuss problems with
  167. X3J11 members, in hopes of reducing the amount of negative
  168. feedback to X3.
  169.  
  170. On 9 Dec. 1988, all three documents plus any feedback from
  171. the commenters are to be submitted to CBEMA's X3 Secretariat
  172. as the official X3J11 proposal for the ANSI Standard for
  173. Programming Language C.  After review by X3, assuming no
  174. problems arise the proposed Standard will then be submitted
  175. to ANSI for official ratification as an ANSI standard.  It
  176.  
  177.  
  178.                            - 4 -
  179.  
  180. seems probable that the final ANSI C standard will be
  181. published some time during 1989.
  182.  
  183. The Watchdog contact person in X3J11 is Doug Gwyn.  He can
  184. be reached at:
  185.  
  186.           Doug Gwyn
  187.           US Army Ballistic Research Lab
  188.           801 L Cashew Ct.
  189.           Belair, MD  21014
  190.           gwyn@brl.mil
  191.           +1 (301) 287-6647
  192.  
  193.  
  194. Volume-Number: Volume 15, Number 37
  195.