From: Bart Trojanowski <bart@jukie.net>
To: Joseph Carter <knghtbrd@debian.org>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: asm/unistd.h
Date: Thu, 5 Apr 2001 10:35:00 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.30.0104051031210.13496-100000@localhost> (raw)
In-Reply-To: <20010405072628.C22001@debian.org>
On Thu, 5 Apr 2001, Joseph Carter wrote:
> On Thu, Apr 05, 2001 at 09:06:20AM -0400, Bart Trojanowski wrote:
> > So you ask: "why not just use a { ... } to define a macro". I don't
> > remember the case for this but I know it's there. It has to do with a
> > complicated if/else structure where a simple {} breaks.
>
> This doesn't follow in my mind. I can't think of a case where a { ... }
> would fail, but a do { ... } while (0) would succeed. The former would
> also save a few keystrokes.
Tim Waugh already stated this one:
#define foo(x) { do_something(x) }
if( condition )
foo(x);
else
foo(y);
would produce
if( condition )
{ do_something(x) };
else
{ do_something(y) };
note the semi-colon at the end of {.*}.
This is bad because it forces you to use the foo macro knowing it's a
macro and not a function.
So you say I will use it like this:
if( condition )
foo(x)
else
foo(y)
That's just great for this case, but now imagine that on some other
architecture doing foo(x) takes many many lines with recursion and all.
You don't want that to be in a macro so you make a function. And you get
many many compiler errors on thsi new platform.
Cheers,
Bart.
--
WebSig: http://www.jukie.net/~bart/sig/
next prev parent reply other threads:[~2001-04-05 14:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-05 12:58 asm/unistd.h Sardañons, Eliel
2001-04-05 13:06 ` asm/unistd.h Bart Trojanowski
2001-04-05 13:12 ` asm/unistd.h Tim Waugh
2001-04-05 14:26 ` asm/unistd.h Joseph Carter
2001-04-05 14:35 ` Bart Trojanowski [this message]
2001-04-05 14:35 ` asm/unistd.h Stephen Thomas
2001-04-05 14:45 ` asm/unistd.h Andreas Schwab
2001-04-05 17:38 ` asm/unistd.h J . A . Magallon
2001-04-05 13:07 ` asm/unistd.h David S. Miller
2001-04-05 13:13 ` asm/unistd.h Ben Collins
2001-04-05 15:23 asm/unistd.h Steve Grubb
2001-04-05 15:41 ` asm/unistd.h Bart Trojanowski
2001-04-05 15:45 ` asm/unistd.h David S. Miller
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.30.0104051031210.13496-100000@localhost \
--to=bart@jukie.net \
--cc=knghtbrd@debian.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®