Code Analyser Error - False Conditional Errors

Is variable preinitialized at compilation time? since all objects or properties are nillified & zeroed out before use variable == 0 is a legit message, may be change the default value of variable to minus 1 and perform the code analysis again and see what it reports ...

You can silence the warning about user-facing strings by changing the code like this:

     [myButton setTitle: NSLocalizedString (@"out of range", @"")];

You don't actually have to provide any localizations, because the output defaults to the first parameter.

>> if(variable == 0) is reported as an error - "Assuming 'variable' is equal 0".

You mean in a situation like the following?

     if(variable == 0)
          [myButton setTitle: @"out of range"];

In that case, the analyzer is showing you one path through your code, the one where variable == 0, which leads to the error it's actually reporting — the error about localization. It's a bit simple-minded, I suppose, since the fact that the setTitle line is optionally executed is kinda irrelevant. You could submit a bug report asking for a less verbose error report for cases like this.

No, the variable is not initialized. It's calculated. For example:

int x = 1;

if(x ==1) //spurious error

No. If there is any non-localized string error in the file, ALL conditional statements are flagged as Assume...

Looking at this further, it looks like not all conditionals are reported as an error. It may be that if()s with a-non localized string in the scope of the conditional are effected. Yes, NSLocalizedString() Fixes it. Still this is a bug. I'll mark your reply as solved.

What I was trying to say was that the message "Assuming 'variable' is equal 0" isn't an error or even a warning, but rather documents the path through the code that leads to the place (or places) where the complaint about localization occurs.

It adds nothing in this case, where the real complaint makes sense locally. In general, though, you end up with a path of execution starting from something like "Assuming XYZ is nil" that traces the effects of that assumption through the code, leading to a point where things would go wrong under that assumption.

Sometimes you have extra information that ensures control can't actually get there, but sometimes you didn't realize that the possibility existed, so you're grateful for the extra verbiage.

I looked at this carefully and what I first said was correct. Even if() statements that do not have a non-localized string in their scope are incorrectly flagged as "Assuming...". These DO NOT assume anything of the sort. This is abug and I heve filed a bug report.

Again, the "assuming…" is not an error, but an execution flow signpost. It means that, with the assumption of "variable == 0" made earlier, execution will go through here. That has nothing to do with whether there is a test of the value at that point.

What's happening is that at every possible bifurcation of the execution path, it's telling you which one it followed, in order to clarify how it got to the point of the error. Obviously, it's not succeeding at clarifying the flow for you.

NO, NO, NO. It's reporting all conditional expressions in the file and there's no assumption of anything in the conditional expressions, they are normal and correct. You can guess that what it means by "Assuming" is that if the conditional was what the error says then it went to the non-localized expression, but this is NOT what it actually says. Also conditional expressions that don't lead to a non-normalized expression are reported.

It would be easier if you gave more complete information :

- the full code after the if statement

- the exact warning or error you get.

But if you are so sure it is a bug, you were right to file a bug (however I think you will be requested more information than what you provided here).