From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: `SCM_MAKE_CHAR ()' signedness issue Date: Mon, 17 Aug 2009 15:41:48 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250538140 6195 80.91.229.12 (17 Aug 2009 19:42:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Aug 2009 19:42:20 +0000 (UTC) Cc: guile-devel To: "carlo\.bramix" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Aug 17 21:42:13 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 1Md85t-0008KJ-69 for guile-devel@m.gmane.org; Mon, 17 Aug 2009 21:42:13 +0200 Original-Received: from localhost ([127.0.0.1]:50881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md85s-0004Ce-Jd for guile-devel@m.gmane.org; Mon, 17 Aug 2009 15:42:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Md85l-00049B-5n for guile-devel@gnu.org; Mon, 17 Aug 2009 15:42:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Md85e-00043i-U3 for guile-devel@gnu.org; Mon, 17 Aug 2009 15:42:03 -0400 Original-Received: from [199.232.76.173] (port=56145 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md85e-00043f-Or for guile-devel@gnu.org; Mon, 17 Aug 2009 15:41:58 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:64865 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Md85W-0000SZ-92 for guile-devel@gnu.org; Mon, 17 Aug 2009 15:41:58 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n7HJfm5L028163; Mon, 17 Aug 2009 15:41:48 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:9142 Archived-At: On Aug 17, 2009, at 14:52, carlo.bramix wrote: > Hello, > if I understood the problem, I think it can be easily fixed without > using an inline function. > > For example: > > #ifdef __GNUC__ Relying on GCC-specific syntax is probably worse than an inline function. Part of Ludovic's complaint was that we don't want to depend on "inline" working in some random compiler; but then, we certainly shouldn't depend on statement expressions working everywhere either. And if you're going to conditionalize GCC and non-GCC versions, you might as well use an inline function in the GCC case, especially since other C99 compilers should support it as well. The machinery in inline.h is set up to deal with that, though it chooses between inline expansion and function calls, not between inline function expansion and macro expansion. I think we can probably argue that if inline function expansion is disabled for some reason in a compiler that does support it, performance is not a key issue; probably "-O" was omitted on the command line or something. So the thought of falling back to a function call in that case really doesn't bother me. (I have written code to rely on GCC-specific extensions before, and code that conditionalizes such things. I think there are cases where you may want to do that. I just don't think this is one of them.) The only benefits I see here to going with the macro are (1) minor performance differences on non-C99, non-GCC compilers, (2) different semantics if some odd type -- like a 64-bit value -- is provided, (3) simpler code, if you just have one version of the macro. Ken