Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.28/text0038.txt

Text File | 1992-08-17 | 11.3 KB | 242 lines

Submitted-by: [e-mail] (Stephen R. Walli)

ANSI X3J11 and ISO/IEC SC22/WG14: C Language


Michael Meissner <[e-mail]> reports on the May 10-15, 1992
meeting in Salt Lake City, Utah:

On May 10-12 of 1992, I attended the ANSI X3J11.1 meeting, and on May
13-15 of 1992, I attended the combined ANSI X3J11 and ISO WG14
meetings.

For those people who aren't aware of how the various committees
interact, and what their charter is, here is a thumbnail sketch. In
the beginning was the ANSI X3J11 committee, which is the American
committee chartered to produce a C standard. The first C standard was
approved in December of 1989, and is available as X3.159-1989. The
X3J11 committee is now doing interpretations, where they have to
answer queries about the standard, but cannot change it.

Around 1988, the ISO WG14 committee was formed to lead the American C
standard through as an international standard. In ISO, each country
gets one vote, and the USA votes through ANSI. After reformatting the
standard and moving some sections around to meet ISO guidelines, the C
standard was approved as an international standard, which is available
as ISO/IEC:9899-1989(E).

At the time the standard was approved, there were three open issues
raised by Japan, Denmark, and England, and there was approval to work
on a normative addenda to address the problems. (These issues are
covered later.)

Around 1989, some people started meeting to discuss numerical issues
and the C language. The committee, originally called NCEG (Numerical
C Extension Group), has since become X3J11.1, a subcommittee of
X3J11. Their charter is to produce a technical report, which does not
have the weight of a ANSI or ISO standard. I suspect many of the
X3J11.1 features will be items to be considered for the next ANSI/ISO
C standard. This committee is made up of various interested parties
who care about floating point calculations.

X3J11.1

X3J11.1 met for the first three days, from May 10 through May 12.

I went to the floating point extensions subgroup on Sunday night. For
the most part, this meeting was uncontroversial. The floating point
extensions group had submitted their draft to a letter ballot which
passed, and the meeting was used to address minor editorial changes
and comments from the ballot. The draft contains the following items:

   - New syntax for floating point constants, so that you can specify
     the exponent and mantissa in hexadecimal, rather than decimal.

   - Printf/scanf %a/%A format specifiers to print the floating number
     in the new hexadecimal format.

   - More math functions.

   - Overloaded math functions - these functions are a step towards
     C++ style overloading: if the arguments are single precision, the
     calculation is done in single precision. Unlike C++, these are
     only required for the system functions and not the user functions.

   - Requirements on exactly when Nan/Infinity/-0 is produced from the
     various match functions if the system uses IEEE 754/854 floating
     point. (Most systems these days use IEEE 754 format).

   - Adding IEEE unordered comparisons (!>, etc.) which return true if
     either value is a Nan, instead of false.

   - Adding floating point classification functions.

   - Ways to get/set exception flags.

   - Two new include files are added.

On Monday and Tuesday, I went to the normal X3J11.1 meetings. The
following items were discussed:

   - The restricted type qualifier proposal had a successful letter
     ballot, and will go outside of X3J11.1 for review. This proposal
     is half-way between the current situation where the compiler
     can't fully vectorize, and noalias, which got shot down before
     the standard went out. It adds a new qualifier, restricted,
     which says that you promise that the given pointer is the only way
     a particular item is referenced. This will allow a function to
     take two restricted pointers, and to fully vectorize the
     accesses, because the compiler doesn't have to worry about
     overlap cases.

   - Automatic variables with variable dimensions were discussed, but
     no conclusion was reached. There are two proposals on the floor,
     one from Cray and the other from USL. The Cray proposal would
     require people to pass the bounds explicitly for arrays, and has
     problems in scoping if the bound is passed after the array. The
     USL proposal which is authored by Dennis Ritchie, would pass a
     ``fat'' pointer, which is a descriptor that contains the bounds
     as well as the pointer. The debate went on as to which was more
     in the spirit of C. I personally tend to favor the USL proposal.

   - Designated initializers will go out for a review. These allow a
     programmer to initialize a structure or array out of order. For
     example:

     struct foo { int a, b; } st = { .b = 1, .a = 2 };
     int foo2[10] = { 1, [5] = 2, 3 };


     (In the array example, element 6 is initialized to '3'). Gcc 2.0
     has a similar feature, though the syntax is slightly different.

   - Compound literals will go out for a review. These allow a
     programmer to create an automatic (or static if at file scope)
     aggregate without having to give it a name. Gcc has this
     feature. For example:

     foo (&(struct bar){ 1, 2 });

   - The floating point extensions draft mentioned earlier was
     approved to go out for a review. One item that will go in a
     cover letter is to warn people that the #pragmas specified may be
     changed into macros, since pragmas are not allowed inside macro
     expansions.

   - The complex arithmetic draft was not ready to be sent out for
     review at this time. The draft needs to be more fully specified
     for IEEE floating point with respect to Nans and Infinities.
     Also, there was concern that the complex functions be folded in
     with the overloaded functions (ie, having just sin instead of
     csin). Finally, some people feel that in addition to real, and
     complex types, there needs to be an imaginary type that has no
     real component, particularly in the case with Nans and Infinities.

   - There was some spirited discussion about extended integers and 64
     bit machines. The 64-bit consortium (vendors who will be
     producing 64 bit CPUs) want the ANSI group to exactly specify
     what sizes short, int, long, etc. are in 64 bit environments.
     Given that ANSI committees typically take years to come down from
     the mountain, and the 64-bit consortium needs to deliver products
     soon, it was hopeless. Also, there are good reasons why the
     standard only gives minimums. The crux of the problem is that
     when you move to 64 bits, programs will break (just like they did
     in moving 16 bits to 32 bits, but there is more extant code in C
     now). No matter what you choose, you break somebody's cherished
     notations. One camp wants int, pointer size, and long to all be
     64 bits, and there is no explicit 32 bit type. Another camp
     wants int to be 32 bits, and pointers/long to be 64 bits.
     Finally at least one person wanted int to be 64 bits and long to
     be 32 bits. The C committee roundly reviled any rule that broke
     the rule that sizeof (int) <= sizeof (long), but otherwise had no
     comments to send back to the 64-bit consortium.

The array syntax subgroup met on Monday night. This group is charged
with doing things to arrays, so that fast code can be generated on the
vectorizers and/or massively parallel machines (essentially Cray vs.
Thinking Machines). The meeting quickly broke down into shouting
matches and such. I felt that it made negative progress, to the point
that the only positive vote was a ``motherhood'' vote on the group's
charter. There was another array syntax subcommittee meeting on
Tuesday night (and possibly Wednesday night also), but I declined to
attend.

ANSI X3J11/ISO WG14

On Wednesday through Friday (May 13 - May 15), the ANSI X3J11 and ISO
WG14 met together. At times the meeting was run in ANSI X3J11 mode,
and at other times it was in ISO WG14 mode. The primary objective for
the ANSI part of the meeting was to answer questions about the
standard. The primary objective of the ISO part of the meeting was to
deal with the three proposed normative addendum.

The U.K. addendum is designed to tighten up the wording of the
standard, but not to make any substantive changes. The goal of the
Japanese addendum is to add additional wide character functions and a
new header in which to declare them. The Danish addendum provides
alternatives to the ANSI trigraphs, while not using any of the
national replacement characters from ISO 646.

The big news is that the ANSI C standard will soon be withdrawn and
replaced with the ISO C standard, so that the standards remain
synchronized. This means that chapter and verse quotations will soon
change, due to paragraph renumbering required by ISO. Also, when the
normative addenda come out, they will become part of the ANSI C
standard, in addition to the ISO C standard.

Some of the decisions reached in talking about the Japanese addenda
include:

   - Wide character I/O functions can return errors if they can't
     translate multibyte <-> wide characters. Errno is set to EILSEQ
     upon such an error.

   - If a wide character value is >= 0 and <= UCHAR_MAX, then the
     single byte character classification functions (isprint(),
     isspace(), etc.) if true, implies that the wide version
     (iswprint(), iswspace(), etc.) is also true. If the single byte
     version is false, it does not imply that the wide version also
     returns false. This is to allow wide characters to fill up
     positions in the encoding that aren't valid single byte values.

   - We voted against adding more support for mixing multibyte and
     wide character strings in the *printf()/*scanf() family of
     functions. The proposal was for %hs to always mean multibyte
     characters in both printf() and wprintf(), %ls would always mean
     wide characters, and %s would mean either multibyte or wide
     characters, depending on whether the function was printf() or
     wprintf().

   - The new function wcswcs() (wide version of strstr()), got renamed
     to wcsstr(), since most people felt that the second

   - We voted not to reserve the wide stdio functions for a future
     standard to put in stdio.h (ie, you always have to include
     wchar.h to properly declare those functions).

   - We voted that no illegal multibyte sequence will be emitted by
     the wide character output routines (including through %S or %C in
     printf()).

   - We voted that only a single byte space terminates scanf(``%S''),
     ie. not iswspace(), to allow for logically ungeting just a single
     byte.


The Danish digraph proposal was shot down (again). I suspect it may
be for the last time, because more countries are concerned about
delaying the rest of the addenda for this one small issue. Japan and
the Netherlands both voiced this opinion for the first time at this
meeting.

There will be letter ballots sent out on the various responses to
interpretation requests. One letter ballot will cover all decisions
in which there were no ``no'' votes at the committee, and one letter
ballot will be sent out for each decision that had at least one ``no''
vote. It is hoped that the draft for the document of interpretation
requests will be passed in the letter ballot, so it can be sent out
for the next meeting (6 months from now).

Volume-Number: Volume 28, Number 40