From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Reference leak in `iprin1 ()' Date: Thu, 17 Nov 2005 10:54:44 +0100 Organization: LAAS-CNRS Message-ID: <87k6f7a9az.fsf@laas.fr> References: <87y83z3vh5.fsf@laas.fr> <4371CF46.4010708@xs4all.nl> <87y83xkcq6.fsf@laas.fr> <8764r18r2j.fsf@zip.com.au> <87wtjghm1m.fsf_-_@laas.fr> <87zmoa2pad.fsf@ossau.uklinux.net> <874q6fsg89.fsf@laas.fr> <87veysjnpm.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1132228298 16538 80.91.229.2 (17 Nov 2005 11:51:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 Nov 2005 11:51:38 +0000 (UTC) Cc: Han-Wen Nienhuys , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 17 12:51:37 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EciIa-00041x-4S for guile-devel@m.gmane.org; Thu, 17 Nov 2005 12:51:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EciIZ-0008Fy-K1 for guile-devel@m.gmane.org; Thu, 17 Nov 2005 06:51:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EcgrJ-0002hs-4I for guile-devel@gnu.org; Thu, 17 Nov 2005 05:19:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EcgjW-0002NV-VI for guile-devel@gnu.org; Thu, 17 Nov 2005 05:11:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EcgU9-0001yT-Sy for guile-devel@gnu.org; Thu, 17 Nov 2005 04:55:21 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EcgU9-00063b-HD for guile-devel@gnu.org; Thu, 17 Nov 2005 04:55:17 -0500 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id jAH9tDlq027381; Thu, 17 Nov 2005 10:55:14 +0100 (CET) Original-To: Neil Jerram X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 27 Brumaire an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , guile-devel@gnu.org, Han-Wen Nienhuys In-Reply-To: <87veysjnpm.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 16 Nov 2005 21:18:45 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:5399 Archived-At: Hi Neil, Neil Jerram writes: > Why? Does () have any symptoms that we should be concerned about? Well, nothing to be really "concerned" about, mostly consistency. In a declaration, `()' has a different meaning than `(void)', but not in the definition. According to section 6.7.5.3 or ISO/IEC 9899:1999: 10 The special case of an unnamed parameter of type void as the only item in the list specifies that the function has no parameters. [...] 14 An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.124) Since, the declarations in `print.h' use `(void)', there's nothing really serious here. >> Below is an updated patch. I modified `PUSH_REF ()' as well so that it >> does PSTATE->TOP++ _after_ using the `PSTATE_STACK_SET ()' macro: this >> is safer. > > Why is it safer? Because of the side effects these macros may introduce, as described in http://gcc.gnu.org/onlinedocs/gcc-4.0.2/cpp/Duplication-of-Side-Effects.html#Duplication-of-Side-Effects . As far as `PUSH_REF ()' is concerned, without knowing all the definitions of all the macros it uses, one can't be sure that PSTATE->TOP won't be incremented more than once. > My inclination is that it's usually safer to change > less code, other things being equal. Agreed. But that must not prevent us from discussing existing code and modifying it when we see fit, i.e. when there is improvement to gain. ;-) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel