All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: root@chaos.analogic.com
Cc: "Hefty, Sean" <sean.hefty@intel.com>,
	Troy Benjegerdes <hozer@hozed.org>,
	infiniband-general@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [Infiniband-general] Getting an Infiniband access layer in theLinux kernel
Date: 06 Feb 2004 09:23:00 -0800	[thread overview]
Message-ID: <52smhounpn.fsf@topspin.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0402061150100.3862@chaos>

    Richard> If some major changes are being considered, I think it's
    Richard> time to get rid of the:

    Richard> do { } while(0) stuff that permiates a lot of MACROS and
    Richard> just use the { } as they were designed.

    Richard> Before everybody screams, think. It's perfectly correct
    Richard> to start a new "program unit" without a conditional
    Richard> expression.  You just add a curley-brace, then close the
    Richard> brace when you are though.

This is totally, totally wrong.  If you get rid of do { } while (0),
then you can't use the macro in an if statement.  Read any C FAQ for
details, or try the following:

    #define MAC(x) { x = x + 1; }

    int main() {
      int x = 0;

      if (1)
        MAC(x);
      else
        x = x - 1;
    }

I get the following (correct) error:

    $ gcc a.c
    a.c: In function `main':
    a.c:8: syntax error before "else"
    $ gcc --version
    gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

because

    if (1)
        { x = x + 1 } ; /* <-- note semicolon
    else
        x = x - 1;

is not correct C.

By the way, it is possible to use parentheses and commas for some
simple macros, so for example the following is OK:

    #define MAC(x) ( x = x + 1, x = x * 2 )

    int main() {
      int x = 0;

      if (1)
        MAC(x);
      else
        x = x - 1;
    }

However I don't see anything wrong with the perfectly standard "do { }
while (0)" idiom.  Certainly if some compiler generates worse code for
that construct that just a plain { }, _that_ is a compiler bug that we
shouldn't have to work around.

 - Roland

  reply	other threads:[~2004-02-06 17:23 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-06 16:42 [Infiniband-general] Getting an Infiniband access layer in theLinux kernel Hefty, Sean
2004-02-06 17:05 ` Richard B. Johnson
2004-02-06 17:23   ` Roland Dreier [this message]
2004-02-06 18:00     ` Richard B. Johnson
2004-02-06 18:12       ` Måns Rullgård
2004-02-06 18:13       ` Chris Friesen
2004-02-06 18:22       ` Valdis.Kletnieks
2004-02-06 18:50         ` Richard B. Johnson
2004-02-06 19:02           ` Matti Aarnio
2004-02-06 19:11           ` Petr Vandrovec
2004-02-07  3:05             ` Jamie Lokier
2004-02-06 18:54         ` Måns Rullgård
2004-02-06 19:01     ` somenath
2004-02-06 17:27 ` Troy Benjegerdes
2004-02-06 18:51 ` Greg KH
2004-02-08  8:31   ` Fab Tillier
2004-02-08 16:29     ` Greg KH
2004-02-08 16:51       ` Fab Tillier
2004-02-09  2:55         ` Troy Benjegerdes
2004-02-09  2:57         ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2004-02-24 17:55 Woodruff, Robert J
2004-02-24 18:03 ` Greg KH
     [not found] <mailman.1076018705.12618.linux-kernel2news@redhat.com>
2004-02-09  1:51 ` Pete Zaitcev
2004-02-08 23:43 Arnd Bergmann
2004-02-08 21:36 Woodruff, Robert J
2004-02-06  4:07 Perez-Gonzalez, Inaky
2004-02-05 23:09 Woodruff, Robert J
2004-02-05 22:55 Woodruff, Robert J
2004-02-05 22:54 ` Randy.Dunlap
2004-02-05 22:26 Hefty, Sean
2004-02-05 22:40 ` Christoph Hellwig
2004-02-05 22:39   ` Randy.Dunlap
2004-02-05 23:19 ` Greg KH
2004-02-06  1:10 ` Troy Benjegerdes
2004-02-05 22:17 Tillier, Fabian
2004-02-05 22:56 ` Brian Gerst
2004-02-05 22:58 ` Bernd Petrovitsch
2004-02-05 22:02 Tillier, Fabian
2004-02-06  1:57 ` Troy Benjegerdes
2004-02-05 20:32 Tillier, Fabian
2004-02-05 21:27 ` Greg KH
2004-02-05 21:56   ` Chris Friesen
2004-02-06 20:22 ` Bill Davidsen
2004-02-05 19:26 Tillier, Fabian
2004-02-05 20:27 ` Greg KH

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=52smhounpn.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=hozer@hozed.org \
    --cc=infiniband-general@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=sean.hefty@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.