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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2013-05-11 23:44:14 UTC ---
The bug reporter's claims about uselocale are blatantly false. The whole point
of uselocale is that you can save, change, and restore the (thread-local)
locale safely from library code. The return value of uselocale is a locale_t
value representing the old locale, which can be restored by passing it back to
uselocale before returning from your library function. See
http://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html

With that said, unless someone is interesting in liaising with the Austin Group
to get additional *_l functions added to Issue 8, I think it's harmful to keep
adding them. To be portable, applications have to include fallback code (#if
!defined(HAVE_LOCALECONV_L), etc.) using uselocale anyway.

Assuming applications/libraries have this code for using uselocale, the only
reasonable motivation for a new *_l function would be that the uselocale
approach is prohibitive from a performance standpoint. I don't see that
applying to localeconv since it just returns data that's constant for the
locale. You can simply call it once and save the results (either the full
result or just the part(s) you need).

-- 
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]