On Sat, Jun 10, 2017 at 12:03:18AM +0200, Gerald Pfeifer wrote: > On Thu, 8 Jun 2017, David Malcolm wrote: > > How about: > > > > "Warn about unsafe multiple statement macros that appear to be guarded > > by a clause such as if, else, while, or for, in which only the first > > statement is actually guarded after the macro is expanded." > > > > or somesuch? > > Yes, I like this. > > On Thu, 8 Jun 2017, Martin Sebor wrote: > > I don't have strong feelings about the current wording but if it > > should be tweaked for accuracy I would suggest to use the formal > > term "controlling expression", similarly to -Wswitch-unreachable. > > That sounds good to me. > > Some comments on the original patch: > > +Warn about macros expanding to multiple statements in a body of a > conditional, > +such as @code{if}, @code{else}, @code{for}, or @code{while}. > > "in the body of a $WHATEVER_WE_SHALL_CALL_IT" It now says something other than that, so that mistake is not there anymore.
> +The can usually be fixed by wrapping the macro in a do-while loop: > > Is there a particular reason for not using an if(1) { } statement? > > Ah, of course, a following else statement would be impacted by that. > Do we want to note that in the documentation? I don't think so, we only suggest do {} while (0);. > +This warning is enabled by @option{-Wall} in C and C++. > > "for C and C++" instead of "in"? Other parts of invoke.text use both, so I left that as it was. I think both work here. > I'm curious to see how many issues this is going to find in real-world > code out there! Yeah, me too. Marek