[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: 16bit ctype table
> 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
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? ;)
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.
Main Index |
Thread Index |