[Top][All Lists]

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

Re: More i18n

From: Neil Jerram
Subject: Re: More i18n
Date: Sun, 31 Dec 2006 16:22:10 +0000
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Neil Jerram <address@hidden> writes:
>> "SuS v2" isn't quite a reason for testing, is it?  I think you need a
>> few more words here.
> I meant that they may not be available everywhere.  I should certainly
> make it clearer.


>> That's a lot of constant definitions!  Did you consider the possibility of
>> any other approach (e.g. symbols)?
> I'm no longer sure it's generally good to use symbol to that end.  It
> creates secondary name spaces where regular module-based access control
> cannot be used.

Good point; agreed.

> There's nothing obliging us to use integers for those constants.  For
> instance, `DAY_1' could be defined as:
>   (define DAY_1 (cons 'a 'b))
> Then, if a piece of code doesn't know (or cannot access) the value of
> `DAY_1', it cannot forge it and consequently cannot get the effect of
> `(language-information DAY_1)'.  This is the same as what happens with
> other bindings.
> Now, as Kevin said, the names are very C-ish...

I think your higher-level interface idea, including Kevin's
locale-weekday etc., would do a good job of covering that up.

>>> +  c_result = strdup (c_result);
>>> +
>>> +  codeset = (char *) alloca (strlen (tmp_codeset) + 1);
>>> +  strcpy (codeset, tmp_codeset);
>> Can we avoid alloca here?  We know from another current thread that
>> some systems don't seem to have it.
> Sure, but `alloca ()' may be faster on most platforms and it avoids
> leaks.  Isn't it just that we should update the `alloca' blob from the
> Autoconf manual?

Yes, quite right; I've been inappropriately concerned about alloca


reply via email to

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