Re: [9fans] strangely typed functions in standard library

[quanstro@quanstro.net]

of course, how an array of Runes is stored is a different issue from how a
Rune argument is passed on the stack (or in a register). 

don't consider this advocacy, but what would break if runes were expanded
to 32 bits?  i think that font handling would need some limits changed,
chartorune and runetochar would need to be modified and some enum
constants in libc.h would need to be changed.  this seems to me to be small
potatoes in comparison to dealing with issues lurking within the basic plane
like character composition.

rob has suggested passing uncomposed characters to libdraw and handling
the problem there.  but there's one problem with that.  how do you stick
a nonspacing horn onto an arbitrary letter?  how do you put a grave accent
on top of that?  (transliterations of cryllic to the roman alphabet use some 
double- and triple- accented letters which do not exist in precombined form
within unicode.)

i modified p9p libdraw at one point to draw combining characters.  (i.e. compose
a zero-width character on top of the previous character.) the results
were not legible.  a+diaresis may have been marginal buit A + " was mud.

this is really annoying.  characters should not combine.  the character-composition
algorithims of tex+metafont shouldn't come hidden within a character set.  

(well that's my 2¢, anyway.  maybe somebody has an idea on how to manage these
issues.)

- erik

p.s. how would you do this?  

> i'd like to map them to RFat ... something unassigned in
> 0xFF.. space.

the problem is that there's not enough free space in the basic plane. and as usual 
with these things invention is the mother of all necessity.


On Thu May 18 04:22:47 CDT 2006, bruce.ellis@gmail.com wrote:
> 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 <quanstro@quanstro.net> wrote:
> > while this is true, i believe that the real reason for this is that
> > on a >=32-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 <rotaerk1@gmail.com> wrote:
> > > > The following functions are described as accepting a Rune, but instead
> > > > 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.
> >
>