guile-devel
[Top][All Lists]
Advanced

[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





reply via email to

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