tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 16bit ctype table



On Mon, Aug 20, 2012 at 09:07:26PM +0900, Takehiko NOZAKI wrote:
> the patch is very similar to the one i posted tech-userlevel few years ago.
> then you have objection, what makes change your mind? ;)

Complains that wasting so much space on the 4 Bytes per elements.
I still don't really care that much either way :)

> 1. don't rename _ctype2_ -> _ctype_ table by hand.
> use __LIBC12_SOURCE__ macro or other trick on src/libc/compat/*/Makefile
> to provide libc.so.{12,13} from same source tree.

I'm not sure I see the point. 

> 2. _CTYPE_* macro should be similar to _RUNETYPE_*.
> once you agreed, aren't you?
> http://mail-index.netbsd.org/tech-userlevel/2011/03/21/msg004738.html
> http://mail-index.netbsd.org/tech-userlevel/2011/03/22/msg004755.html
> 
> my old patch, relation of _CTYPE_* and _RUNETYPE_* is:
> 
>     (_CTYPE_A << 8) == _RUNETYPE_A
> 
> we already lost it by adding _CTYPE prefix done by you
> there is no need to consider legacy.

Well, advantage of keeping them as is would be to minimize the
translation for the old ctype table. I'm fine with adding that to the
ToDo list for the libc major bump though. One thing I do care about is
that code using the old interface breaks when re-compiled. GCC is
important in this regard.

Joerg


Home | Main Index | Thread Index | Old Index