From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-1-18-g904a78f Date: Tue, 04 Aug 2009 18:11:24 +0200 Message-ID: References: <87fxcd92pg.fsf@gnu.org> <1249149509.12325.7535.camel@localhost.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1249413785 30960 80.91.229.12 (4 Aug 2009 19:23:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Aug 2009 19:23:05 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Mike Gran Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Aug 04 21:22:57 2009 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 1MYPb5-0005WF-R7 for guile-devel@m.gmane.org; Tue, 04 Aug 2009 21:22:56 +0200 Original-Received: from localhost ([127.0.0.1]:49443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYPb5-0006lw-3V for guile-devel@m.gmane.org; Tue, 04 Aug 2009 15:22:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MYPaz-0006kJ-Ip for guile-devel@gnu.org; Tue, 04 Aug 2009 15:22:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MYPau-0006j9-3x for guile-devel@gnu.org; Tue, 04 Aug 2009 15:22:48 -0400 Original-Received: from [199.232.76.173] (port=50733 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYPat-0006j6-V9 for guile-devel@gnu.org; Tue, 04 Aug 2009 15:22:43 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:49667 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MYPaq-0003OD-7j; Tue, 04 Aug 2009 15:22:40 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 6380120CF6; Tue, 4 Aug 2009 15:22:39 -0400 (EDT) Original-Received: from unquote (unknown [82.123.246.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id B603120CF4; Tue, 4 Aug 2009 15:22:36 -0400 (EDT) In-Reply-To: <1249149509.12325.7535.camel@localhost.localdomain> (Mike Gran's message of "Sat, 01 Aug 2009 10:58:29 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 2C914B00-812C-11DE-BD8D-F699A5B33865-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:9027 Archived-At: Hi Mike, Another niggle: On Sat 01 Aug 2009 19:58, Mike Gran writes: > On Fri, 2009-07-31 at 01:21 +0200, Ludovic Court=C3=A8s wrote: >> "Michael Gran" writes: >> > +#define SCM_MAKE_CHAR(x) ({scm_t_int32 _x =3D (x); = \ >> > + _x < 0 = \ >> > + ? SCM_MAKE_ITAG8((scm_t_bits)(unsigned char)_x, scm_tc8_char)= \ >> > + : SCM_MAKE_ITAG8((scm_t_bits)_x, scm_tc8_char);}) >>=20 >> This macro uses a GCC extension, which is not acceptable for Guile. Can >> you please rewrite it in standard C? (The only risk is multiple >> expansion of X, but that's OK.) > > OK. There was one case of multiple expansion causing side effects, but, > I fixed that. Could we not just fix invokers of SCM_MAKE_CHAR() with negative values? Are there instances of this outside Guile's source tree whose behavior we need to preserve? That would avoid the multiple expansion problem neatly, which the future would appreciate. >> Does X < 0 mean ASCII? And why is it truncated to 8 bits? A comment >> just above indicating the encoding trick would be handy IMO. > > OK. Wide chars are always positive, but, the upper 128 of signed 8-bit > C chars are negative, which is the reason for that logic. I see. How irritating. Well, I guess that's fine, then -- barring a requirement for SCM_LITERAL_CHAR or something. >> Style (extraneous braces). > > Noted. If that's the standard then so be it. But, for this case, I > declare, in classic flamewar fashion, that the standard is nonsense. :) It is better that we follow the standard, though. Cheers, Andy --=20 http://wingolog.org/