home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0095.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  1.5 KB  |  36 lines
  1. Submitted-by: peterw@spaten.sharebase.com (Peter Wisnovsky)
  2.  
  3. In article <16ccqfINNrss@ftp.UU.NET> decot@cup.hp.com (Dave Decot) writes:
  4. >POSIX.1 and POSIX.2 say nothing whatsoever
  5. >about wchar_t.  ISO C makes no requirement conflicting with using Unicode
  6. >(or any 16 bit codeset where there is an all-zero code available for
  7. >the null wide character) in wchar_t.
  8.  
  9. Perhaps I am mixing up my terminology or not expressing myself clearly
  10. (where is Marlin Fitzwater when you need him?) My knowledge of the
  11. various standards organizations is somewhat sketchy. However, my
  12. impression of what the potential problem is that if the standards orgs
  13. went ahead and used wchar_t as the vehicle for supporting Unicode,
  14. then existing conformant implementations that define wchar_t to be an
  15. 8-bit or 32-bit value would be made non-conformant. NT is not
  16. non-conformant in itself...but the solution it proposes to the storage
  17. of Unicode data, that is, the fixing of the size of wchar_t to be
  18. 16=bits wide, would not work with existing conformant systems.
  19.  
  20. Two proposals were discussed at the Unicode conference wrt XPG. One
  21. would be to have the standards changed so that wchar_t would be
  22. defined to be 16-bits wide; the other would be to create a new
  23. datatype, `unichar'. The sentiment at the conference was to create a
  24. new datatype.
  25.  
  26. Peter Wisnovsky
  27. -- 
  28.  
  29. UUNET:   peterw@sharebase.com
  30. US Mail: ShareBase Corporation - 1919 Addison Ave. - Berkeley, CA 94704
  31. Phone:   (510) 548-3211
  32.  
  33.  
  34. Volume-Number: Volume 28, Number 97
  35.  
  36.