From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: More i18n Date: Sun, 31 Dec 2006 16:22:10 +0000 Message-ID: <8764bsavd9.fsf@ossau.uklinux.net> References: <877iwzokpz.fsf@chbouib.org> <87mz5uqkvx.fsf@ossau.uklinux.net> <878xhdxyyo.fsf@laas.fr> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1167582147 7862 80.91.229.12 (31 Dec 2006 16:22:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 31 Dec 2006 16:22:27 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 31 17:22:26 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H13S2-00077Z-RX for guile-devel@m.gmane.org; Sun, 31 Dec 2006 17:22:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H13S2-0007HX-8Y for guile-devel@m.gmane.org; Sun, 31 Dec 2006 11:22:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H13Ry-0007DW-Pw for guile-devel@gnu.org; Sun, 31 Dec 2006 11:22:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H13Ry-0007Cr-3u for guile-devel@gnu.org; Sun, 31 Dec 2006 11:22:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H13Ry-0007Ck-0r for guile-devel@gnu.org; Sun, 31 Dec 2006 11:22:18 -0500 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H13Rx-0002OI-In for guile-devel@gnu.org; Sun, 31 Dec 2006 11:22:17 -0500 Original-Received: from laruns (host86-145-157-83.range86-145.btcentralplus.com [86.145.157.83]) by mail3.uklinux.net (Postfix) with ESMTP id 23D1540A9A2 for ; Sun, 31 Dec 2006 16:22:17 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 231366F711 for ; Sun, 31 Dec 2006 16:22:10 +0000 (GMT) Original-To: guile-devel@gnu.org In-Reply-To: <878xhdxyyo.fsf@laas.fr> ( =?iso-8859-1?q?Ludovic_Court=E8s's_message_of?= "Tue, 12 Dec 2006 10:09:19 +0100") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6384 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > Neil Jerram 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 =3D strdup (c_result); >>> + >>> + codeset =3D (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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel