Re: ctype, chrtbl, rune tables and POSIX2008

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On Wed, Jan 18, 2012 at 10:42:23PM +0000, YAMAMOTO Takashi wrote:
>> >> i'm not sure if it's a good idea because
>> >> 
>> >> - uselocale is acutally being used by third party code in the wild.
>> >> 
>> >> - uselocale is in standard.
>> >> 
>> >> - sometimes uselocale is the only choice.
>> >>   eg. when calling a library which internally uses locale-sensitive 
>> >> functions.
>> > 
>> > The problem is that it adds the TLS access overhead for all the
>> > locale-sensitive functions.
>> 
>> isn't it avoidable with a global
>> uselocale_has_ever_been_used_for_this_process variable?
> 
> I don't know. I just saw a report on the FreeBSD lists that the
> uselocale() stuff add a significant overhead (78%?) to some common
> operations. It requires a lot more work e.g. for ctype(3) and in fact,
> it breaks the ABI (silently). That sounds like a good reason to not
> support it.

hm, i forgot the inlined ctype mess.  good point.
i don't think there's a sane way to make uselocale to work for them
without changing the ABI.

> 
>> > Further complications are added by VAX and
>> > Sun2 still not supporting TLS. It seems like a strong hack around for
>> > broken code.
>> 
>> can't they use a plain setspecific?
> 
> That makes the code more even more ugly.

i consider a few #ifdef for now acceptable.
for long term, they need TLS anyway.

> 
>> >> >> is the rest of his patch ok for you?
>> >> > 
>> >> > Looking at the latest version, I don't agree with using _ all over the
>> >> > place. I think it would help to clean up dead code first -- is there a
>> >> > good reason for keeping CITRUS optional? Getting rid of that helps for
>> >> > all the patches in the area (ctype, multi-locale etc). After having only
>> >> > a single implementation, we can easily go over each function set and
>> >> > merge it individually.
>> >> 
>> >> the size of libc is the only reason to have it optional i'm aware of.
>> >> but i even don't know how much it makes libc smaller/bigger.
>> > 
>> > joerg@britannica:/tmp/with-citrus$ size libc.so.12.179 
>> >    text       data     bss     dec     hex filename
>> > 1136427      47232   65752 1249411  131083 libc.so.12.179
>> > 
>> > joerg@britannica:/tmp/without-citrus$ size libc.so.12.179 
>> >    text       data     bss     dec     hex filename
>> > 1101773      41984   63832 1207589  126d25 libc.so.12.179
>> > 
>> > That's AMD64 with Clang. Does the small difference really justify the
>> > complexity?
>> 
>> thanks for providing numbers.
>> it seems not worth the complexity to me.
>> but i guess an x86-only guy like me is not a right person to judge. :-)
>> 
>> i remembered another possible problem; the size of statically linked 
>> binaries.
>> eg. a single printf pulled in a lot of locale stuff.
> 
> Let's take bin/cat as example:
> 
>    text          data     bss     dec     hex filename
> 163956           4396   19912  188264   2df68 with-citrus/cat
> 147756           4136   19912  171804   29f1c without-citrus/cat

thanks.

my feeling is that the bloat is acceptable.

YAMAMOTO Takashi

> 
> Joerg