
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 5, 2011, at 1:20 AM, Chandler Carruth wrote:</div><blockquote type="cite"><div class="gmail_quote">On Wed, Oct 5, 2011 at 1:10 AM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com">atrick@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Thanks for cleaning up. But broken? No, I just can't train myself to insert redundant parens in this idiom.</blockquote></div><br><div>Heh, and on the other side it took me thinking about this more than I like admitting to convince myself that indeed, ((X || Y) && "...") is equivalent to (X || (Y && "..."))... Oh well, probably means that's enough coding for one evening. ;]</div>

</blockquote></div><br><div>I don't want anyone to have to think about binary operator precedence to read my code--I'm not picking on you. My point was that the compiler should know this idiom is ok if it's going to warn people in the general case. I only brought it up on the list because I make this mistake *all the time* using LLVM's assert idiom, so your cleanup won't be the last of its kind. After many years using asserts heavily in C++ (with good macros, not the silly keyword),  the mechanical process of shuffling expressions around between if statements and asserts and adding comments to asserts is completely subconscious. I never visually parse the string as part of the expression then go out of my way to add parens in the rare case that they're needed.</div><div><br></div><div>clang doesn't warn about this, which is good, but there is some value in emulating gcc's bad behavior.</div><div><br></div><div>-Andy</div></body></html>