Re: 16bit ctype table

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Oct 07, 2012 at 02:43:50AM +0900, Takehiko NOZAKI wrote:
> > It is quite a technical issue.
> 
> we talking about ABI problem of libc major bump, isn't it ?

I don't think we are talking about doing a libc major bump at this
point. Before netbsd-7 maybe, but not now.

> all your claims is cosmetic. if you don't like it, you can paint
> bikesched your favorite color later.
> it is not the reason for NAK my patch for more than 19 months.

Sorry for dropping the ball a while ago to work on other things.

> > I don't see how any platform definition of _RUNETYPE_A
> 
> i think _RUNETYPE_* stuff  must be get rid of in the future(as i
> wtrote in previous mail).
> use _CTYPE_* in mklocale(or POSIX localedef), old 4.4BSD rune must be
> die in terms of it's bad design.
> difficulty of _Rune* struct spawned many bugs like lib/46781 and
> latency of setlocale(3).

I don't think dropping _RUNETYPE_* buys anything. We still need more data
for wchar operations like the width. I don't think this has any relation
to the rune code either. For the latency of setlocale(3) it would help
if it didn't have to do anything at all for the ctype. That was one
argument for using the _RUNETYPE_* macros directly, even for ctype(3).
There is one problem at the moment related to _RUNETYPE_* not being
endian-fixed, but that would be a separate discussion.

> so we use _CTYPE_* for crosstool'ed mklocale(1) directly, and it must
> be redefining it for portability.
> (i had split ctype.h and sys/ctype_bits.h several years before for this 
> reason).

We don't use _CTYPE_* in mklocale(1). Even if we did, just pulling in
our definitions last would be good enough without introducing yet
another macro set.

Joerg