Re: 16bit ctype table

[Takehiko NOZAKI <takehiko.nozaki%gmail.com@localhost>]

> My point is that we need to keep both tables until the major bump.
> Minimising the differences between them keeps the runtime impact as
> small as possible. I am all for reducing the difference further, but
> until the major bump, the old table won't go away.

to clarify difference:

fundamentally, your patch and mine is not so differ.
  * both libc.so.12 should have 8bit old ctype table and 16bit new ctype table
  * both libc.so.13 have only 16bit new ctype table.
so that aparently there is *no* diffrence libc's size impact.

*only* diffrence is 16bit bitmask pattern.

1. _CTYPE_* is not same layout with _RUNETYPE_*, keep old layout (by joerg)
  * partial source code compatibility.
  * complex rune table -> ctype table conversion, by bogus _runetype_to_ctype().

2. _CTYPE_*  is same layout with _RUNETYPE_* (by tnozaki)
  * simple rune table -> ctype table conversion,  (_CTYPE_A << 8) == _RUNETYPE_A
  * no source code compatibiliy.

in my opinion again:

1. source code compatibility
in this case, it is not important, because _CTYPE_* is completely
*private* macro.
there's someone(such as libstdc++) use it and took an arrow in his
knee, i don't mind.

if you don't agree with me, why you  do following change? ;)
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/ctype_bits.h.diff?r1=1.1&r2=1.2

2. rune table -> ctype table conversion
simple conversion is good for reading, maintanance, and our health.
especially peformance, POSIX2008's multi-locale wants low-latency LC_CTYPE.


> We don't use _CTYPE_* in mklocale? Only the rune version.
oops, -current not used yet(in my private tree use it, hehe).
but in the future, we better to _CTYPE_* supersede _RUNETYPE for localedef(1).

very truly yours.
-- 
Takehiko NOZAKI<takehiko.nozaki%gmail.com@localhost>