mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: arjan@infradead.org, akpm@osdl.org, tglx@linutronix.de,
	mingo@elte.hu, rmk+lkml@arm.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] genirq: ARM dyntick cleanup
Date: Wed, 5 Jul 2006 17:02:52 -0700	[thread overview]
Message-ID: <20060705170252.4dc73eb8.rdunlap@xenotime.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0607051626380.12404@g5.osdl.org>

On Wed, 5 Jul 2006 16:53:22 -0700 (PDT) Linus Torvalds wrote:

> 
> 
> On Wed, 5 Jul 2006, Randy.Dunlap wrote:
> > 
> > OK, I'll bite.  What part of Linus's macro doesn't work.
> 
> Heh. This is "C language 101".

Yes, I got most of that.  :)
more below.

> The reason we always write
> 
> 	#define empty_statement do { } while (0)
> 
> instead of
> 
> 	#define empty_statement /* empty */
> 
> is not that
> 
> 	if (x)
> 		empty_statement;
> 
> wouldn't work like Arjan claimed, but because otherwise the empty 
> statement won't parse perfectly as a real C statement.
> 
> In particular, you tend to get much better error messages if you have 
> syntax errors _around_ the empty statement if it's done as that 
> "do { } while (0)" thing. You also avoid compiler warnings about 
> empty statements or statements without effects, that you'd get if you were 
> to use
> 
> 	#define empty_statement /* empty */
> 
> or
> 
> 	#define empty_statement 0
> 
> for example (a expression statement is a perfectly valid statement, as is 
> an empty one, but many compilers will warn on them).
> 
> It's also simply good practice - if you _always_ do the "do { } while (0)" 
> thing, you'll never get bitten by having a macro that has several 
> statements inside of it, and you'll also never get bitten by a macro that 
> is _meant_ to be used as a statement being used as part of an expression 
> instead.
> 
> It basically boils down to the fact that the "do { } while (0)" format is 
> always syntactically correct, /regardless/ of what is inside of the 
> braces, and should always give you meaningful error messages regardless of 
> what is _around_ the macro usage.

Yes, I already understood that.  I was interested in Arjan's
specific example, which was:

if (foo())
	zyzzy();

in which he supplied the terminating semi-colon, and which Andrew
explained with the -W warning...

> For example:
> 
> 	if (a)
> 		empty_statement
> 	b;
> 
> will give the _correct_ syntax error message ("expected ';'"), instead of 
> silently turning into
> 
> 	if (a)
> 		b;
> 
> or other nonsense.

OK, good practice, yes.

> But in the end, the real aim is to just teach your fingers to _always_ put 
> the do/while(0) there, so that you never EVER write something like
> 
> 	#define MACRO one; two;
> 
> which really breaks down.
> 
> This is, btw, the same reason a lot of people (including me, most of the 
> time) will write
> 
> 	#define VALUE (12)
> 
> instead of writing the simpler
> 
> 	#define VALUE 12
> 
> just because it's good practice to _always_ have the parentheses around 
> a macro that ends up being used as an expression.
> 
> So we always also write
> 
> 	#define ADD(a,b) ((a)+(b))
> 
> because otherwise you eventually _will_ get bitten (we've had that 
> particular bug bite us in the *ss lots of times, even though people should 
> know better)

Yes, I have the () macro practice down.  I was just looking for the
problem with that one specific example, which you and Andrew have now
explained.  Thanks.

---
~Randy

  reply	other threads:[~2006-07-06  0:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-03  0:18 Thomas Gleixner
2006-07-03  0:35 ` Andrew Morton
2006-07-03  6:29   ` Thomas Gleixner
2006-07-03  6:57     ` Ingo Molnar
2006-07-04 11:54       ` Christoph Hellwig
2006-07-04 12:22         ` Ingo Molnar
2006-07-05  8:35           ` Russell King
2006-07-08 18:53         ` Christoph Hellwig
2006-07-03  7:41   ` Russell King
2006-07-03  7:55     ` Andrew Morton
2006-07-03  9:03       ` Russell King
2006-07-03  9:12         ` Andrew Morton
2006-07-03 16:56       ` Linus Torvalds
2006-07-03 17:13   ` Linus Torvalds
2006-07-03 17:27     ` Arjan van de Ven
2006-07-05 23:24       ` Randy.Dunlap
2006-07-05 23:35         ` Andrew Morton
2006-07-05 23:50           ` Randy.Dunlap
2006-07-05 23:53         ` Linus Torvalds
2006-07-06  0:02           ` Randy.Dunlap [this message]
2006-07-06  6:47           ` Giacomo A. Catenazzi

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=20060705170252.4dc73eb8.rdunlap@xenotime.net \
    --to=rdunlap@xenotime.net \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=tglx@linutronix.de \
    --cc=torvalds@osdl.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

Powered by JetHome