home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / unix / 382 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  2.0 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: peterw@spaten.sharebase.com (Peter Wisnovsky)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: POSIX update
  5. Date: 14 Aug 1992 13:33:06 -0700
  6. Organization: NCR/ShareBase Corporation
  7. Lines: 34
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <16h5a2INNko4@ftp.UU.NET>
  11. References: <16b9drINNero@ftp.UU.NET> <16ccqfINNrss@ftp.UU.NET>
  12. Reply-To: peterw@spaten.sharebase.com (Peter Wisnovsky)
  13. NNTP-Posting-Host: ftp.uu.net
  14. X-Submissions: std-unix@uunet.uu.net
  15.  
  16. Submitted-by: peterw@spaten.sharebase.com (Peter Wisnovsky)
  17.  
  18. In article <16ccqfINNrss@ftp.UU.NET> decot@cup.hp.com (Dave Decot) writes:
  19. >POSIX.1 and POSIX.2 say nothing whatsoever
  20. >about wchar_t.  ISO C makes no requirement conflicting with using Unicode
  21. >(or any 16 bit codeset where there is an all-zero code available for
  22. >the null wide character) in wchar_t.
  23.  
  24. Perhaps I am mixing up my terminology or not expressing myself clearly
  25. (where is Marlin Fitzwater when you need him?) My knowledge of the
  26. various standards organizations is somewhat sketchy. However, my
  27. impression of what the potential problem is that if the standards orgs
  28. went ahead and used wchar_t as the vehicle for supporting Unicode,
  29. then existing conformant implementations that define wchar_t to be an
  30. 8-bit or 32-bit value would be made non-conformant. NT is not
  31. non-conformant in itself...but the solution it proposes to the storage
  32. of Unicode data, that is, the fixing of the size of wchar_t to be
  33. 16=bits wide, would not work with existing conformant systems.
  34.  
  35. Two proposals were discussed at the Unicode conference wrt XPG. One
  36. would be to have the standards changed so that wchar_t would be
  37. defined to be 16-bits wide; the other would be to create a new
  38. datatype, `unichar'. The sentiment at the conference was to create a
  39. new datatype.
  40.  
  41. Peter Wisnovsky
  42. -- 
  43.  
  44. UUNET:   peterw@sharebase.com
  45. US Mail: ShareBase Corporation - 1919 Addison Ave. - Berkeley, CA 94704
  46. Phone:   (510) 548-3211
  47.  
  48.  
  49. Volume-Number: Volume 28, Number 97
  50.