From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190605180221l79cf7214m7116dfe7567af85d@mail.gmail.com> Date: Thu, 18 May 2006 19:21:35 +1000 From: "Bruce Ellis" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] strangely typed functions in standard library In-Reply-To: <78ef64122fed7daa18548b4984d01a8b@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <78ef64122fed7daa18548b4984d01a8b@quanstro.net> Topicbox-Message-UUID: 51e3b324-ead1-11e9-9d60-3106f5b1d025 32 bit unicode is not Rune friendly ... i hope Runes don't get fatter. it will break many things. rob has had something to say about this, do a search on the list. i'd like to map them to RFat ... something unassigned in 0xFF.. space. use them at your peril. brucee On 5/18/06, erik quanstrom wrote: > while this is true, i believe that the real reason for this is that > on a >=3D32-bit machine, an ushort can just be declared > to be a long by the compiler whereas the compiler must emit > instructions to convert a long to an unsigned short. > > - erik > > On Tue May 16 10:10:37 CDT 2006, 0xef967c36@gmail.com wrote: > > On 5/16/06, Matt Stewart wrote: > > > The following functions are described as accepting a Rune, but instea= d > > > the parameters are of type long. Why? > > > > > > int runelen(long); > > > char *utfrune(char *, long); > > > char *utfrrune(char *, long); > > > > full unicode is 32 bit, even if plan9 (afaik) > > supports only characters in the BMP. >