This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15459] RFE: Add |localeconv_l()| to allow porting of FreeBSD/OSX applications...
- From: "jakub at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 12 Jul 2013 05:25:16 +0000
- Subject: [Bug libc/15459] RFE: Add |localeconv_l()| to allow porting of FreeBSD/OSX applications...
- Auto-submitted: auto-generated
- References: <bug-15459-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15459
Jakub Jelinek <jakub at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at redhat dot com
--- Comment #13 from Jakub Jelinek <jakub at redhat dot com> ---
(In reply to Rich Felker from comment #12)
> > The workaround is useless. On OSX uselocale() is expensive (~ 200 times the
> > time of a single malloc(100)) and adding manual code to copy the data requires
> > a free function which requires a API redesign.
>
> Then this seems like a bug in OSX, not glibc. The whole point of
> uselocale is to be able to use it like this. If it's prohibitively
> slow, that's a serious QoI issue. If it's also slow on glibc, then the
> slowness, not the lack of the *_l function, is the bug that should be
> addressed.
Yeah, that sounds like a serious flaw in OSX (one of many), even on very slow
Linux box I can run 100000000 uselocale calls in a second.
If uselocale is so slow on OSX, then it doesn't surprise me they wanted to add
functions like localeconv_l, but the whole point of uselocale is that it is
very fast and *_l functions are there mainly for APIs that are often
implemented inline and just dereference some data pointed by the locale_t
handle.
--
You are receiving this mail because:
You are on the CC list for the bug.