bgg@pta.oz.au (Ben Golding) (12/29/90)
Recently, I was asked about the ISO C standard which I wasn't aware of. Can someone tell me when it was adopted (if it has)? How does it differ from ANSI C? Are there different levels like ISO Pascal? Ben.
rex@aussie.COM (Rex Jaeschke) (01/11/91)
> Recently, I was asked about the ISO C standard which I wasn't aware of. > Can someone tell me when it was adopted (if it has)? How does it > differ from ANSI C? Are there different levels like ISO Pascal? As the US international rep to ISO C committee WG14 I can answer that. ISO C is completed. It is technically equivalent to ANSI C. ANSI and ISO now use the same format for standards but did not when X3J11 started so the ANSI std had to be significantly reformatted to make an ISO std document. Alas, the line number refs were not permitted to remain. This conversion has been done. I believe the document is wending its way through the ISO maze for final processing. New work is continuing in WG14. Several national groups are heading up projects which will eventually result in one or more `normative addenda.' The UK is adding clarification wording to many parts of the std but NOT adding/changing/deleting substantive stuff. The Japanese are working full steam on extra multibyte library support. The Danish are working on their alternate trigraph proposal. It is expected that in a couple of years one or more of these addenda will be completed and accepted by member nations in some form. At that time they will be added to the ISO C std and WILL HAVE the full weight of a std. At that point ISO C becomes a proper superset of ANSI C. Whether these addenda are retrofitted back into the ANSI std or not remains to be seen. (I foresee subsetting eventually for this reason: FIPS is based on the current ANSI C std. FIPS reflects the needs of govt agencies in the US. If a new ANSI std adopts all of the ISO addenda it's possible FIPS could not use that new ANSI C std since alternate trigraphs or multibyte support [for example] are NOT mandatory requirements for US govt business. So does FIPS then make its own std? No I think it better they require ANSi C Level X and not the other options.) However, it does seem reasonable that at some time in the future the ANSI std will take on the ISO format to make it easier to reconcile the 2 stds. At this stage David Prosser of AT&T is the redactor of both stds. I don't know how that will work once the addenda come together since they are being produced by others. At the Sep X3J11 meeting the officers of X3J11 proposed that X3J11 consider moving ALL NEW C STD WORK to the ISO arena AND ALSO, EVENTUALLY, INTERPRETATIONS. This is under consideration. The interpretations MUST be done by X3J11 for at least the foreseeable future but new work will almost certainly be restricted to the ISO level. Since it is acknowledged by both X3J11 and WG14 that the bulk of the technical expertise lies within X3J11 the two committees have agreed to meet jointly once a year (every 2 meetings under our current schedule). As such, a joint meeting will be held in Milan, Italy Dec 11-13. Re my Numerical C Extentions Group. In Sep SPARC approved it as a working group within X3J11 (tentatively X3J11.1). There was 1 NO vote: that we should produce a std rather than a report. The parent body X3 has yet to do so. In Nov, WG14 adopted NCEG as is as a rapporteur group within WG14. NCEG has the same role in both committees; to research numerical extensions and publish a Technical report (tentatively sometime in 1992). So NCEG stuff has impact in the ISO arena now as well and it is mostly invention. However, its a report NOT a binding std. Another issues being raised at ISO level is more open support for extended national characters in identifiers and the idea of a compile-time locale. Rex ---------------------------------------------------------------------------- Rex Jaeschke | Journal of C Language Translation | C Users Journal (703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL rex@aussie.COM | Reston, Virginia 22091, USA | Programmers Journal ---------------------------------------------------------------------------- Convener of the Numerical C Extensions Group (NCEG) ----------------------------------------------------------------------------
henry@zoo.toronto.edu (Henry Spencer) (01/11/91)
In article <3440@pta.oz.au> bgg@pta.oz.au (Ben Golding) writes: >Recently, I was asked about the ISO C standard which I wasn't aware of. >Can someone tell me when it was adopted (if it has)? How does it >differ from ANSI C? Are there different levels like ISO Pascal? ISO C is still being worked on. Many people hope that its technical content (as opposed to issues of wording and editorial organization, which ISO and some of the people involved with it are neurotic about) will be identical to ANSI C. There are people agitating for changes, however. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
domo@tsa.co.uk (Dominic Dunlop) (01/15/91)
In article <52.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes: [Goodness me. Hadn't expected Rex to be in Oz -- and on the net -- already.] > > ISO C is completed. > > It is technically equivalent to ANSI C. > > ANSI and ISO now use the same format for standards but did not when X3J11 > started so the ANSI std had to be significantly reformatted to make an ISO > std document. Alas, the line number refs were not permitted to remain. This > conversion has been done. I believe the document is wending its way through > the ISO maze for final processing. Thanks for the well-drawn picture. Glad to hear that we'll have an ISO standard for C just as soon as the Information Technology Task Force (the name by which the ISO bureaucracy knows itself) is through with its process. You may be interested to know that IEEE Std. 1003:1:1990, the POSIX Operating System interface standard, is identical to ISO 9945-1:1990 except for the cover (the IEEE's is prettier). After months (possibly years) of heavy-duty wrangling, the IEEE Standards Office and ITTF reached agreement on a common document layout and, at the last minute, ITTF decided to let IEEE print the ISO version as well as its own -- provided that the document appeared on international standard-sized A4 paper. This is why 1003.1:1990 is the first IEEE standard to appear on un-American paper. ITTF even agreed, after holding out almost until the end, to let the line numbers remain in the ISO version. (After all, ITTF had for some time been using the line numbers in its requests for changes to successive drafts.) It may be that ITTF could be prevailed upon, even at this late stage, to retain line numbers in the C standard, now that a precedent has been set. On the other hand, it may be unwise to rock the boat... -- Dominic Dunlop