home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / std / unix / 407 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  2.2 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: gwyn@smoke.brl.mil (Doug Gwyn)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: POSIX update
  5. Date: 31 Aug 1992 12:50:51 -0700
  6. Organization: U.S. Army Ballistic Research Lab, APG MD.
  7. Lines: 37
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <17tt6rINNm0k@ftp.UU.NET>
  11. References: <16p6g6INNs4i@ftp.UU.NET> <17bncrINNrpe@ftp.UU.NET> <17e68qINNj6j@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. Keywords: posix, unicode, iso10646
  14. X-Submissions: std-unix@uunet.uu.net
  15.  
  16. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  17.  
  18. In article <17e68qINNj6j@ftp.UU.NET> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
  19. >The C standard explicitly allows a ``byte'' to be more than eight
  20. >bits, and 16-bit Unicode bytes is a very reasonable decision in some
  21. >contexts. But it might be that POSIX has additional requirements that
  22. >make it impossible for such a system to conform --- and if the POSIX
  23. >committee had been aware of Unicode, it would have made sense to avoid
  24. >such a conflict.
  25.  
  26. IEEE Std 1003.1 also predated ISO 10646.
  27.  
  28. Anyway, during X3J11/WG14 debates over the best way to support large
  29. character sets, most vendors were not willing to make "char" anything
  30. other than an 8-bit datum, due to existing code such as network
  31. interfaces where the 8-bit "char" assumption was pervasive.  Of course
  32. one could argue that that was poorly designed code in the first place,
  33. but it was deemed to be economically important to continue to assign
  34. exactly 8 bits for "char" in many environments.  If it had not been
  35. for that consideration, both the Japanese "long char" and my own
  36. "short char" alternatives would probably have received more committee
  37. support.
  38.  
  39. (I have seen nothing in the intervening years to make me think that
  40. the so-called "short char" proposal is not technically the best
  41. alternative.)
  42.  
  43. >It is true that the first DIS 10646 (which had nothing to do with
  44. >Unicode) could be fitted into the multibyte framework, even though
  45. >the intention seems to have been ...
  46.  
  47. Sorry, that's what I meant.  For historical reasons some of us lump
  48. all the variations on IBM's Unicode AND (D)IS 10646 into the same
  49. bucket.  However, it's IS 10646 that matters for this forum.
  50.  
  51.  
  52. Volume-Number: Volume 29, Number 19
  53.