🚀 go-pugleaf

Submitted-by: peterw@spaten.sharebase.com (Peter Wisnovsky)

In article <16ccqfINNrss@ftp.UU.NET> decot@cup.hp.com (Dave Decot) writes:
>POSIX.1 and POSIX.2 say nothing whatsoever
>about wchar_t.  ISO C makes no requirement conflicting with using Unicode
>(or any 16 bit codeset where there is an all-zero code available for
>the null wide character) in wchar_t.

Perhaps I am mixing up my terminology or not expressing myself clearly
(where is Marlin Fitzwater when you need him?) My knowledge of the
various standards organizations is somewhat sketchy. However, my
impression of what the potential problem is that if the standards orgs
went ahead and used wchar_t as the vehicle for supporting Unicode,
then existing conformant implementations that define wchar_t to be an
8-bit or 32-bit value would be made non-conformant. NT is not
non-conformant in itself...but the solution it proposes to the storage
of Unicode data, that is, the fixing of the size of wchar_t to be
16=bits wide, would not work with existing conformant systems.

Two proposals were discussed at the Unicode conference wrt XPG. One
would be to have the standards changed so that wchar_t would be
defined to be 16-bits wide; the other would be to create a new
datatype, `unichar'. The sentiment at the conference was to create a
new datatype.

Peter Wisnovsky
-- 

UUNET:   peterw@sharebase.com
US Mail: ShareBase Corporation - 1919 Addison Ave. - Berkeley, CA 94704
Phone:   (510) 548-3211


Volume-Number: Volume 28, Number 97