Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!dclsic!sjc!leia!harkcom From: harkcom@spinach.pa.yokogawa.co.jp Newsgroups: comp.std.c Subject: Re: wchar_t values Message-ID: Date: 11 Apr 91 23:54:47 GMT References: Sender: news@leia.pa.yokogawa.co.jp Organization: Yokogawa Electric Corporation, Tokyo, Japan Lines: 23 In-reply-to: mleisher@nmsu.edu's message of 11 Apr 91 12:05:55 GMT In article mleisher@nmsu.edu (Mark Leisher) writes: =}While we're on the subject of wchar_t, has anyone experimented with =}implementing a libc sort of setup for wchar_t I/O? Any suggestions on =}approaches? SVR4 contains routines for I/O using wchar_t in both 16 bit and 32 bit sizes. Details can be found in the "Multi-National Language Supplement". =}Also supported are string functions specifically for =}the wchar_t type. I wrote the library because I cannot for the life =}of me get the LC_CTYPE stuff on our Suns to cooperate for mbcs tables The wstrings.c file in kinput also contains routines for handling wide characters. But it has a lot of error checking stuff than can be chucked... The problem with using such libraries is that they can only be used when the encoding of the input matches the one the library uses. The object of using locales is to remove such dependencies... Al