[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More i18n
Re: More i18n
Sun, 31 Dec 2006 16:22:10 +0000
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