7

I'm writing a program that is supposed to solve a sudoko-like puzzle, Hashiwokakero. I have some code that looks like this:

if (bridgesLeft[row][col] == 1)
{
   doSomething();
}
else if (bridgesLeft[row][col] == 2)
{
   doSomethingElse();
}
else if (bridgesLeft[row][col] == 3)
{
   doAnotherThing();
}
...

I realized that I put a bug in the doSomethingElse() function, so rather than deleting that block, I added else if (bridgesLeft[row][col] == 2 && false) to guarantee that the buggy function wouldn't run, just to make sure that was where my bug was coming from. Xcode gave me a warning, saying my doSomethingElse() code would never run. It also gave me this option:

fix-it: Silence by adding parentheses to mark code as explicitly dead.

Clicking on this button changes 

else if (bridgesLeft[row][col] == 2 && false)

to

else if (bridgesLeft[row][col] == /* DISABLES CODE */ (2) && false)

How do parentheses around the '2' mark this code as explicitly dead? What does this mean? If I leave the parentheses in, but take the && false part out, the code block is still executed, so it's not actually making the code dead.

usr1234567
  • 21,601
  • 16
  • 108
  • 128
DJMcMayhem
  • 7,285
  • 4
  • 41
  • 61
  • The compiler knows that `whatever && false` is false and will probably get rid of the whatever part. I guess this is more relevant if a function call is this whatever part. Putting that function call into parentheses might indicate that something odds happening. – usr1234567 Mar 20 '15 at 22:23
  • 2
    Not a solution, but maybe comment out the method call instead of fiddling with your logic. You might go back in a few weeks, months and not know why you did that. It is good practice to change it to `// doSomethingElse() temp remove because of bug in doSomethingElse`. – vrwim Mar 20 '15 at 22:28
  • I personally would disable/ignore that particular warning (at least in debug builds), as it is PROBABLY not useful most of the time. In "release" builds, where you are supposedly producing "production" code, it may be useful to know this. Although I'm a great fan of enabling warnings, some are pretty useless when you are in middle of developing something (one I have turned off is "unused member variable", because I often build classes by adding the member variables first, and stub out the actual functions until I get round to actually implement those) – Mats Petersson Mar 20 '15 at 22:49

1 Answers1

6

This does not fix the problem as much as silence the warning by telling clang that the code is meant to be dead, we can see this by reading Improve -Wunreachable-code to provide a means to indicate code is intentionally marked dead via if((0)) which says:

Log: Improve -Wunreachable-code to provide a means to indicate code is intentionally marked dead via if((0)).

Taking a hint from -Wparentheses, use an extra '()' as a sigil that a dead condition is intentionally dead. For example:

if ((0)) { dead }

When this sigil is found, do not emit a dead code warning. When the analysis sees:

if (0)

it suggests inserting '()' as a Fix-It.

From what I can tell it is just looking for an integer literal in (), which in your case the (2) fits this case and silences the warning.

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • Hmmm, wouldn't it recommend `if (bridgesLeft[row][col] == 2 && (false))`? Wouldn't it put the parentheses around the part that actually makes it dead? – DJMcMayhem Mar 21 '15 at 02:02
  • @DJMcMayhem: I'd expect `if ((bridgesLeft[row][col] == 2) && false)` but you could be right as well. – usr1234567 Mar 21 '15 at 10:00
  • Thanks for the update. I'd consider it a bug in Xcode and file a bug report. – usr1234567 Mar 22 '15 at 09:51