🚀 go-pugleaf

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <17e68qINNj6j@ftp.UU.NET> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>The C standard explicitly allows a ``byte'' to be more than eight
>bits, and 16-bit Unicode bytes is a very reasonable decision in some
>contexts. But it might be that POSIX has additional requirements that
>make it impossible for such a system to conform --- and if the POSIX
>committee had been aware of Unicode, it would have made sense to avoid
>such a conflict.

IEEE Std 1003.1 also predated ISO 10646.

Anyway, during X3J11/WG14 debates over the best way to support large
character sets, most vendors were not willing to make "char" anything
other than an 8-bit datum, due to existing code such as network
interfaces where the 8-bit "char" assumption was pervasive.  Of course
one could argue that that was poorly designed code in the first place,
but it was deemed to be economically important to continue to assign
exactly 8 bits for "char" in many environments.  If it had not been
for that consideration, both the Japanese "long char" and my own
"short char" alternatives would probably have received more committee
support.

(I have seen nothing in the intervening years to make me think that
the so-called "short char" proposal is not technically the best
alternative.)

>It is true that the first DIS 10646 (which had nothing to do with
>Unicode) could be fitted into the multibyte framework, even though
>the intention seems to have been ...

Sorry, that's what I meant.  For historical reasons some of us lump
all the variations on IBM's Unicode AND (D)IS 10646 into the same
bucket.  However, it's IS 10646 that matters for this forum.


Volume-Number: Volume 29, Number 19