home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0018.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.7 KB  |  39 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <17e68qINNj6j@ftp.UU.NET> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
  4. >The C standard explicitly allows a ``byte'' to be more than eight
  5. >bits, and 16-bit Unicode bytes is a very reasonable decision in some
  6. >contexts. But it might be that POSIX has additional requirements that
  7. >make it impossible for such a system to conform --- and if the POSIX
  8. >committee had been aware of Unicode, it would have made sense to avoid
  9. >such a conflict.
  10.  
  11. IEEE Std 1003.1 also predated ISO 10646.
  12.  
  13. Anyway, during X3J11/WG14 debates over the best way to support large
  14. character sets, most vendors were not willing to make "char" anything
  15. other than an 8-bit datum, due to existing code such as network
  16. interfaces where the 8-bit "char" assumption was pervasive.  Of course
  17. one could argue that that was poorly designed code in the first place,
  18. but it was deemed to be economically important to continue to assign
  19. exactly 8 bits for "char" in many environments.  If it had not been
  20. for that consideration, both the Japanese "long char" and my own
  21. "short char" alternatives would probably have received more committee
  22. support.
  23.  
  24. (I have seen nothing in the intervening years to make me think that
  25. the so-called "short char" proposal is not technically the best
  26. alternative.)
  27.  
  28. >It is true that the first DIS 10646 (which had nothing to do with
  29. >Unicode) could be fitted into the multibyte framework, even though
  30. >the intention seems to have been ...
  31.  
  32. Sorry, that's what I meant.  For historical reasons some of us lump
  33. all the variations on IBM's Unicode AND (D)IS 10646 into the same
  34. bucket.  However, it's IS 10646 that matters for this forum.
  35.  
  36.  
  37. Volume-Number: Volume 29, Number 19
  38.  
  39.