[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.
Thanks.
>> 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
recently!
Regards,
Neil