unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: "carlo\.bramix" <carlo.bramix@libero.it>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: `SCM_MAKE_CHAR ()' signedness issue
Date: Mon, 17 Aug 2009 15:41:48 -0400	[thread overview]
Message-ID: <E707BE5F-495B-45CA-87E1-B4F2D814E08C@raeburn.org> (raw)
In-Reply-To: <KOJB4B$8FF6D576AD9DB3B321948833C044C82D@libero.it>

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




  reply	other threads:[~2009-08-17 19:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 18:52 `SCM_MAKE_CHAR ()' signedness issue carlo.bramix
2009-08-17 19:41 ` Ken Raeburn [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-08-18 18:39 carlo.bramix
2009-08-18 18:54 ` Mike Gran
2009-08-18 23:36   ` Greg Troxel
2009-08-15 12:00 Ludovic Courtès
2009-08-16 21:58 ` Ken Raeburn
2009-08-16 22:13   ` Ludovic Courtès
2009-08-16 22:25     ` Ken Raeburn
2009-08-17  8:26       ` Ludovic Courtès
2009-08-17 13:05         ` Mike Gran
2009-08-17 15:33           ` Ludovic Courtès
2009-08-18 17:32             ` Mike Gran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E707BE5F-495B-45CA-87E1-B4F2D814E08C@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=carlo.bramix@libero.it \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).