Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!dclsic!sjc!leia!harkcom From: harkcom@spinach.pa.yokogawa.co.jp Newsgroups: comp.windows.x Subject: Re: Unicode; Internationalizing char sets Message-ID: Date: 16 Mar 91 14:25:31 GMT References: <1671@pai.UUCP> <1991Feb26.094326.3341@ugle.unit.no> Sender: news@leia.pa.yokogawa.co.jp Organization: Yokogawa Electric Corporation, Tokyo, Japan Lines: 33 In-reply-to: mleisher@nmsu.edu's message of 27 Feb 91 14:04:53 GMT In article mleisher@nmsu.edu (Mark Leisher) writes: =}>Perhaps delaying the internationalization of X is a good idea. Who =}>wants potentially major modifications staring them in the face after =}>choosing one international character set over another. =} =}Thanks to Bob Scheifler for alerting me to this (wrong) little gem =}from my last posting. =} =}As he pointed out to me, internationalization efforts are primarily =}oriented towards programming interfaces that provide codeset =}independence as opposed to being dependent on a particular codeset. But your question was useful in that it prompted me to ask myself some others. And one of those questions seems to point to a potential pitfall. The type wchar_t will be supported in X. X can be used over a network. wchar_t can be defined to have different sizes on two different machines as the only requirement is that it be large enough to support all locales on one machine (one machine has largest size of 2 bytes while another has 3 or 4, particularly 4). Now suppose we have a machine, A, running the server and it has wchar_t defined as unsigned short. Now I remotely run a client on another machine, B, which has wchar_t defined as unsigned int. I use the display on A for the client. The client sends a text string which has only two bytes per character in the four byte format to the server. The server will draw a mess. And the reverse (server on B client on A), will make an even prettier mess. Has there been an attempt to avoid this situation? If so, how?