[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WIP: PATCH 0/2] memory leak + uselocale
From: |
Miguel Ángel Arruga Vivas |
Subject: |
[WIP: PATCH 0/2] memory leak + uselocale |
Date: |
Tue, 13 Oct 2020 21:11:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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
signature.asc
Description: PGP signature
- [WIP: PATCH 0/2] memory leak + uselocale,
Miguel Ángel Arruga Vivas <=