grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext.c patch: reuse memory


From: Carles Pina i Estany
Subject: Re: gettext.c patch: reuse memory
Date: Sun, 29 Nov 2009 09:36:33 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

Hello,

On Nov/29/2009, Robert Millan wrote:
> On Sun, Nov 29, 2009 at 12:49:50AM +0000, Carles Pina i Estany wrote:

[...]

> > With the attached patch, gettext module saves in a list the
> > translations.  So if a user asks again for the same translation it
> > returns the same pointer to the already allocated string instead of a
> > new one.

[...]

> How does GNU gettext handle this?  I suspect it could be simpler.

The part of code about is here:
http://cvs.savannah.gnu.org/viewvc/gettext/gettext-runtime/intl/dcigettext.c?revision=1.41&root=gettext&view=markup

(search for the line that contains "Since tfind/tsearch manage a
balanced tree")

I hope that I'm not mistaken: they use a balanced tree to re-use the
translations. Now we are using a list.

> For example, is it practical to allocate a big chunk of memory for the whole
> .mo, then return pointers to it?

I have thought to return a pointer to a const char* that gets reused on
the next _("XX"); (like QByteArray.data() in Qt). But this is not the
standard behaviour of gettext utils and one can have mistakes like:

const char* msg = _("hello %s");
grub_printf(_("Welcome..."));

grub_printf(msg,%user);

Where msg in the grub_printf has been already reused.

We can agree that gettext in Grub behaves in this way and force the
users to copy the strings (Solution B)

If I understood correctly Vladimir in the IRC suggested to translate on
the same char* that it's passed to _( ) (resize if needed), but I don't
like since it's not the standard behaviour and it's by definition a
const char* (for the cases that it's _("hello") , etc.)

In IRC we thought to implement the same behaviour with a hash table but
at the moment this doesn't look necessary at all and too complex for
what we need. But I'm open to keep discussing it.

I suspect that a Grub2 use will handle about 10 or 15 strings in memory.
And more strings if the user uses the Grub console, like maybe 100 or
200. The magnitude of the problem is to have 200 strings in memory that
are or are not being used. I have some functions to debug it, when I
will gettexttize more files I will the exact number.

So, the only thing that I would do is the first behaviour and force the
users the duplicate the strings. If we prefer so tell me and I will
implement it as soon as possible.

-- 
Carles Pina i Estany
        http://pinux.info




reply via email to

[Prev in Thread] Current Thread [Next in Thread]