Two groups have attempted to merge those dialects, and other even larger character sets, into one huge, comprehensive code set. The ISO group calls its offering ISO 10646. An industry group has developed a similar but different offering called UNICODE.

Standard C provides two ways to encode large character sets
as multibyte sequences and as large integers called "wide characters." That subtlety is apparently lost on outsiders, however.

Thus, the ISO 10646 people have complained because the C Standard conflicts with the use of this code set for wide characters. (It's a great multibyte code.) And the UNICODE people have made a code set that causes problems if used as multibyte sequences. (It's a great wide-character code.)

The trouble is, UNICODE is being put forth as a multibyte code. As such, it contains embedded null characters that drive C programmers crazy. And the UNICODE people seem to be winning the fight. Their attitude as victors is that we old-fashioned C programmers just have to modernize our techniques. They certainly shouldn't have to change their code set just to satisfy twenty-year-old conventions in one programming language.

My attitude is that C is the quintessential language for manipulating characters. We C programmers have taught the world a thing or three about how to do it right. The character set folk should listen to the voice of experience if they want a code set that is easy to manipulate in C or any other language.

Obviously, we can live with an encoding that contains embedded nulls. Equally obvious to me is that we can live much better with one that does not. It's too early to guess the outcome of this latest slugfest, but I believe it is an important one to the C community. Please stay alert for opportunities to contribute to the decision. The world needs your informed opinion, whichever side you favor.

P.J. Plauger
pdp@wsa.oz
uunet!munnari!wsa.oz!pjp