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

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2013-05-14 22:07:11 UTC ---
Of course libraries can save and restore the locale with uselocale. That's the
whole point of the uselocale function. There is NO WAY this can affect correct
code, because if your library is using locale, it's calling functions that are
async-signal-unsafe, and thus signal handlers that interrupt your library can
only call async-signal-safe functions. There are no async-signal-safe functions
whose behavior depends on locale; in fact this is one of the contraindications
for specifying a function to be async-signal-safe.

> ... and don't get me started with the performance implications of wrapping
> _every_ library call with |saved_locale=uselocale(mylocale); ... ;
> (void)uselocale(saved_locale);|

Have you measured the performance implications? In any case, nobody said to
wrap every single library call. A number of *_l functions exist, especially for
functions like is*_l which are expected to have very short runtime and for
which cycling uselocale would be proportionally high overhead. As already
noted, localeconv returns data which is _constant_ for the locale in question,
and thus there's no need to call it more than a small finite number of times.

I am not 100% opposed to adding more *_l functions, but your arguments for
doing so, so far, are a mix of invalid (the library-safety issue) and
unconvincing (the performance issue).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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]