https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69237
--- Comment #7 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Franz Sirl from comment #2)
> Or the '--fcount;'. Does the warning go away if you add braces like that:
>
> void pop(T* elem) { SkASSERT(fCount > 0); if (elem) { *elem =
> (*this)[fCount - 1]; } --fCount; }
>
> Or add the closing brace after the '--fCount;' in case that's the correct
> code behaviour. I believe the warning is justified here.
IIRC, the current heuristic for one-liners is to emit the warning iff there
isn't anything before the "if". So we should emit a warning for:
if (elem) *elem = (*this)[fCount - 1]; --fCount;
^ WARN HERE
but not for:
something (); if (elem) *elem = (*this)[fCount - 1]; --fCount;
^ DON'T WARN HERE.
For this case:
void pop(T* elem) { SkASSERT(fCount > 0); if (elem) *elem =
(*this)[fCount - 1]; --fCount; }
we have the unfortunate case that the thing before it in a line is (presumably)
conditionally compiled, so I believe that the presence of the warning will be
affected by whether SkASSERT is enabled. That said, the fix is trivial (to add
braces).
