[Bug c/69415] -Wmisleading-indentation warns on "if (__b < __a) return __b; return __a;"

redi at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Jan 21 16:57:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69415

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #1)
> Jonathan: do you have a sense of how likely we are to see the above
> construct in copies of the STL lurking in 3rd-party codebases?  (or, indeed,

I'd be surprised if many such things exist.

> people compiling their own STL implementations with gcc 6)

I don't think this has anything to do with the STL, or the C++ standard library
in general, IMHO it's just as likely to occur in any C++ code (the resipMin
example is nothing to do with the standard library).

The author of the old libstdc++ code obviously wanted to keep the function body
to a single line, which isn't something unique to std::lib writers :-) That
case is different to the resipMin one though, the old libstdc++ code has the
braces on the same line, which doesn't cause any warning.

It's certainly common for member functions defined in the class body to be
written like:

struct X {
  Y* foo() const { if (m_foo) return *m_ptr; return nullptr; }
};

but again, there's no indentation because the braces are all on the same line.

In the resipMin example the braces are on separate lines. My guess is that's
fairly uncommon, but the warning doesn't seem helpful in that case anyway:
nobody is going to think the second return is guarded by the if, because it
immediately follows another return.

I think the returns in this example make it very different from:

  if (b) do_something(); do_something_else();

Also, when the entire function body is on a single line (except possibly the
braces) it's debatable whether there is any "indentation" at all, let alone
misleading indentation :-)


More information about the Gcc-bugs mailing list