This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/15459] RFE: Add |localeconv_l()| to allow porting of FreeBSD/OSX applications...


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]