public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15459] RFE: Add |localeconv_l()| to allow porting of FreeBSD/OSX applications... Date: Sat, 11 May 2013 23:44:00 -0000 [thread overview] Message-ID: <bug-15459-131-yGKDYphxER@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-15459-131@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2013-05-11 23:44 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-11 1:18 [Bug libc/15459] New: " roland.mainz at nrubsig dot org 2013-05-11 1:27 ` [Bug libc/15459] " roland.mainz at nrubsig dot org 2013-05-11 3:26 ` carlos at redhat dot com 2013-05-11 23:44 ` bugdal at aerifal dot cx [this message] 2013-05-14 14:17 ` carlos at redhat dot com 2013-05-14 17:02 ` bugdal at aerifal dot cx 2013-05-14 19:02 ` carlos at redhat dot com 2013-05-14 21:50 ` roland.mainz at nrubsig dot org 2013-05-14 22:07 ` bugdal at aerifal dot cx 2013-06-16 4:30 ` bugdal at aerifal dot cx 2013-07-12 1:47 ` carlos at redhat dot com 2013-07-12 2:44 ` wendlin1974 at gmail dot com 2013-07-12 2:54 ` wendlin1974 at gmail dot com 2013-07-12 3:20 ` bugdal at aerifal dot cx 2013-07-12 5:25 ` jakub at redhat dot com 2014-06-13 13:24 ` fweimer at redhat dot com 2015-08-27 22:14 ` [Bug locale/15459] " jsm28 at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-15459-131-yGKDYphxER@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).