home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / unix / 384 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  1.9 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: 14 Aug 1992 23:02:18 -0700
  6. Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
  7. Lines: 28
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <16i6laINNssj@ftp.UU.NET>
  11. References: <15rucjINNdov@ftp.UU.NET> <166v0lINNpj8@ftp.UU.NET> <16b9drINNero@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. Keywords: posix, unicode, iso10646, microsoft windows nt
  14. X-Submissions: std-unix@uunet.uu.net
  15.  
  16. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  17.  
  18. In article <16b9drINNero@ftp.UU.NET> peterw@spaten.sharebase.com (Peter Wisnovsky) writes:
  19. >In article <166v0lINNpj8@ftp.UU.NET> mckee@imail.compaq.com (George McKee) writes:
  20. >>Not to mention the reports that Microsoft NT will be POSIX compliant when
  21. >>it appears.
  22. >Not really in terms of character set support. My understanding is that
  23. >they are going to fix wchar_t at 16 bits to store Unicode data, which
  24. >strictly speaking is non-conformant.
  25.  
  26. What's not standard conforming about that?  Indeed, it is not possible
  27. to treat Unicode as a "multi-byte character encoding" according to the
  28. C standard; there is a discussion of this in C Information Bulletin # 1.
  29.  
  30. >Unfortunately there seems to be no satisfactory way to imbed Unicode
  31. >within the EUC framework used in AT&T's MNLS system, which I understand
  32. >is their implementation of Posix international language support.
  33.  
  34. The promoters of Unicode were informed of the (numerous) problems in
  35. fitting Unicode into the existing practice, reflected in Standard C
  36. multibyte character support, but basically they responded that
  37. character sets were more fundamental than programming languages and
  38. that they would therefore ignore the impact of their work on
  39. programming languages, it being the languages' responsibility to
  40. use whatever they came up with.  Some attitude!
  41.  
  42.  
  43. Volume-Number: Volume 28, Number 99
  44.