iosxcodereturnsemantics

How to change XCode ios SDK compiler settings to allow void return statements for non void methods?


I have been asked to update a old ios application built in Xcode 3.1 with some ios 6 features.

When I tried building the source using my xcode 4.5, it refuses to compile because there are numerous places in the project where simple return statements are used in methods which actually is supposed to return a boolean or similar value.

Xcode 3.1 allows it and 4.5 does not. Somewhere in the middle, apple decided to add this restriction.

My problem is that the code is over 20,000 lines of code and the developers have used the simple return statements where ever they needed the method to stop execution. Since the compiler stops compilation when it encounter's the first of these errors, I have to fix it one at a time and then try compiling it again only to find another error. I tried like 2 hours fixing 100s of such return statements.

Is there a compiler flag or Xcode build setting that would change these errors as warnings and allow me to run this app on Xcode 4.5?

This is the exact error that Xcode throws :

/Users.../Classes/WaterMaps.m:5471:5: Non-void method 'initWithParams:mass:radius:totalAssetInfo:' should return a value

Please help..


Solution

  • This has nothing to do with Xcode, but with the compiler. And not Apple added this restriction, the compilers are not from Apple, they are OpenSource projects (GCC and LLVM/clang).

    May I ask why it took you 2 hours to fix 100 such return statements? Fixing 100 such return statements shouldn't take much longer than 5 minutes.

    1. Write return 0; somewhere, select it, copy it to clipboard (CMD+C), delete it again.
    2. Write return; somewhere, select it, hit CMD+E to copy it to search buffer, delete it again.
    3. Go to your source code.
    4. Hit CMD+G which means "find next".
    5. If the found expression is not marked as error, go to (4).
    6. Hit CMD+V (paste), which overwrites return; with return 0;.
    7. Got to (4).

    So basically you keep hitting CMD+G to jump through the file and CMD+V whenever you see an error. To quickly jump to the next file, open the error view in Xcode:

    enter image description here

    Select the first error of the first file and whenever your CMD+G procedure reaches the end of the file, hit CMD+' which jumps to the first issue of the next file on the list. As a developer, you should really learn to use your keyboard more effectively. Keeping your hands on the keyboards makes you hundreds of times more productive than going forth and back between keyboard and mouse/touchpad/trackball/etc.

    And how is the amount of code lines ("over 20'000 lines of code") even relevant? It's the amount of return statements that is relevant.

    Your code is currently seriously broken and instead of wasting time on thinking how to make this broken code compile, I strongly recommended that you should rather go and fix it. Since once fixed, it will work forever and not break again the next time the compilers are updated and your last hack doesn't work any longer.

    I mean how shall a compiler know what you want to return for a method that returns a boolean or an int value if you only type return? The suggested `return 0;' works for all methods that return a numeric value (including floating point) and booleans (0 = false/NO) and makes the compiler happy again. It is the same value that was returned by ancient C compilers in that case.

    Note that even in Xcode 3.1 those return statements should have produced warnings all over the place. As a serious developer, always treat all warnings as errors. You project should not have any warnings. Warnings tell you that there is something wrong or at least there might be something wrong and that means you should go out and fix it. Almost all warnings can be silenced by modifying your code. So instead of ignoring warnings or disabling them in the compiler, fix them. Many companies have a zero warning policy today and if your code produces only a single warning, it is rejected. If the author of this code had treated all warnings as errors, you wouldn't have to fix those now.