From: somenath <somenath@veritas.com>
To: Roland Dreier <roland@topspin.com>
Cc: root@chaos.analogic.com, "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: Fri, 06 Feb 2004 11:01:36 -0800 [thread overview]
Message-ID: <4023E490.7060608@veritas.com> (raw)
In-Reply-To: 52smhounpn.fsf@topspin.com
That's one of the many reasons of using do-while macros..
Other than compilation error, it may generate wrong code too!
this is a FAQ in kernel newbies , look at:
http://www.kernelnewbies.org/faq/index.php3#dowhile
thanks, som.
Roland Dreier wrote:
> 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
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Infiniband-general mailing list
>Infiniband-general@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/infiniband-general
>
>
next prev parent reply other threads:[~2004-02-06 18:57 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
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 [this message]
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=4023E490.7060608@veritas.com \
--to=somenath@veritas.com \
--cc=hozer@hozed.org \
--cc=infiniband-general@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@topspin.com \
--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.