Path: utzoo!attcan!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: ISO WG14 politics
Keywords: ISO WG14 C standard politics
Message-ID: <13253@smoke.BRL.MIL>
Date: 27 Jun 90 15:28:37 GMT
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

I've been informed that I used too broad a brush when I described
the British representatives as having "conspired" with the Danes
at the SC22 plenary session that produced the work item for a
"normative addendum" to address "ambiguities and character set issues".
(The "ambiguities" part concerned the British Standards Institute
concerns while the "character set" part concerned the Danish proposal).
Apparently, there are differences of opinion within the British
delegation, with some members attempting to pursue the Seattle working
agreement between WG14 and X3J11 and others apparently simply trying to
make some political statement about ISO not "rubber stamping" a US
standard.  Also, apparently at least some BSI members are well aware
that there is not international support for the Danish proposal, and do
not intend to support it.  Meanwhile, the Japanese have submitted a
proposal to add wchar_t library function support beyond the minimum
that was said to suffice when it was brought before X3J11.

My personal point of view is that it would be a practical and economic
disaster for the ISO C standard to contradict the ANSI C standard,
which after all has bent over backward to accommodate justifiable
international concerns.  Based on previous evidence, I also have no
confidence in the correctness of any substantive changes that might be
attempted by WG14.  Consequently, I strongly urge that added
functionality such as wchar_t library support be done in a way that
is compatible with the ANSI standard; for example, including prototypes
in a separate header, not requiring that they appear in standard
headers where ANSI C forbids such extensions.  While changes such as
making wchar_t a basic data type instead of a typedef cannot be allowed,
library extensions done in a compatible way are perfectly reasonable.
In fact, it was easy to predict that there would be a demand for such
wchar_t library functions (I predicted it during the long char vs.
short char vs. wchar_t debates); standardizing such extensions is
certainly a proper ISO/WG14 function.  Deliberate incompatibility with
the ANSI standard is not.