Comment 5 for bug 1613662

Useful comments from the developer list:

Mathog:
> There are instances where coding logic as a one time loop is convenient
> because then "break" may be used instead of "goto". In some programming
> projects a religious dispute results if a goto is employed, and this
> avoids that conflict.
> As in:
>
> // not really a loop
> while(1){
> if(condition1)break;
> //code
> if(condition2)break;
> //code
> //etc.
> break;
> }
>
> The object file coming out of the compiler probably differs not at all
> from the goto variant, since the unconditional entry and the final
> unconditional break tells it that this isn't really a repeating section
> of code.

Here, the analyser says: ‘I'm not sure what the author really wanted this code to do.’ and is just not very clever as it's quite clear in the code.

Michael Soegtrop:
> I would be careful with the this!=NULL statement for
>
> bool SPLPEItem::performPathEffect
>
> as far as I can tell, this is not a virtual function, and there is no
> reason why the this pointer of a non virtual function should not be
> NULL. One can call a non virtual member function on a NULL pointer. Not
> very nice, but some people put such checks into the code as extra safety
> check on purpose and some even use tricks like calling a function on
> NULL pointers on purpose, e.g. for saving a lot of checks when the
> function is called.

Therefore the comment ‘this expression is always false on newer compilers, because 'this' pointer can never be NULL’ by the analyser is probably wrong.