From: "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com>
To: guile-devel@gnu.org
Subject: [WIP: PATCH 0/2] memory leak + uselocale
Date: Tue, 13 Oct 2020 21:11:59 +0200 [thread overview]
Message-ID: <87h7qy0wlc.fsf@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]
Hi, everybody,
I've been looking into giving some updates to certain interfaces that
may be useful and uselocale was one of the first I thought---not the
first, but the first for which I send a patch.
Currently, i18n.c reads:
/* XXX: We don't define it as `LC_GLOBAL_LOCALE' because of bugs as of
glibc <= 2.11 not (yet) worked around by Gnulib. See
http://sourceware.org/bugzilla/show_bug.cgi?id=11009 for details. */
I've checked the bug, and I think that the current behaviour of libc is
completely compliant with POSIX. The only two positive mentions to
LC_GLOBAL_LOCALE I've found are in uselocale[1] and duplocale[2]
specifications, and the third explicitly says that it is undefined
behaviour to provide it to newlocale[3] or freelocale[4]. I consider
that they provide a complete framework for the use of this special
object.
In addition, exposing that kind of interface to the Scheme world seems
quite forced, from my point of view. I propose an interface for
uselocale that deduplicates the information from the unique return
value, that is mandatory in the cold cold C world, to *two* values:
first a boolean, that indicates if there is/was a thread-specific locale
installed, and the locale in use before the call as the second value.
If it's called without parameters just returns the value, while the
following call:
(uselocale #f)
Is equivalent to the cryptic:
setlocale (LC_GLOBAL_LOCALE);
The usual interface:
(uselocale anything-not-false)
Provides a locale object that will be installed in the current locale,
or fails if the type is not the adecuate or other system reason, of
course. The returned value is always a smob that must enter the GC
world, so the call to duplocale is needed anyway.
Nonetheless, one of the main use cases would be the guarded execution
idiom, so I also expose an interface called 'with-thread-locale'. The
current implementation is in C with dynamic-wind underneath and a simple
macro over it, but the documentation contains a possible implementation
in Scheme too.
It's only implemented it under USE_GNU_LOCALE_API and needs more work to
be completely ready, as probably the function should be moved to the
posix module (?), but the code it's working---as always, on my machine.
And as a secondary ramification, looking into the other condition (when
USE_GNU_LOCALE_API is not defined) I found something that seems to be a
memory leak, but I don't know where to test it---I don't know which
systems don't define it, nothing I have running right now at least.
The order of the patches is the inverse of the mail, as I wrote the
first before finishing the second, sorry if that causes any confusion.
What do you think? Any ideas or points I may have missed? Suggestions?
Happy hacking!
Miguel
--
[1] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/uselocale.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/duplocale.html
[3] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/newlocale.html
[4] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/freelocale.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
next reply other threads:[~2020-10-13 19:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 19:11 Miguel Ángel Arruga Vivas [this message]
2020-10-13 19:14 ` [WIP: PATCH 1/2] memory leak Miguel Ángel Arruga Vivas
2020-10-13 19:15 ` [WIP: PATCH 2/2] uselocale Miguel Ángel Arruga Vivas
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7qy0wlc.fsf@gmail.com \
--to=rosen644835@gmail.com \
--cc=guile-devel@gnu.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: link
Be 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).