gwyn@smoke.BRL.MIL (Doug Gwyn) (06/27/90)
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.
rja@edison.cho.ge.com (rja) (06/29/90)
Doug Gwyn's comments are very well taken indeed and I heartily agree. I've worked on international software for some while now (dating back to a thesis I wrote on the topic of computers handling the Japanese and Chinese languages) and the Danish proposal is needless and not useful even in their peculiar environment. There are other reasonable approaches to handling their environment that would not place the undue burden that the Danish proposal constitutes. I share the concern about the lack of library support for wide characters. I'm not sure that there is sufficient existing practice in the area to really warrant changing the standard. If changes do come to pass at the ISO level to add additional wchar_t library support, I agree that such changes should be in a separate wide character library(libraries) and be made in a manner consistent to and conforming with the existing ANSI standard. I am also concerned because there are at least two different standards for the size of character sets larger than 8 bits (in particular there are different groups working on both 16-bit standards and 32-bit standards). The 16-bit vs. 32-bit problem I believe to be inappropriate to try to resolve at this time. I do rather wish that the committee had gone with 'long char' rather than wchar_t, but I can live with the decision already made. Randall Atkinson randall@virginia.edu Opinions are solely those of the author.