Re: New Defects reported by Coverity Scan for ceph

["Adam C. Emerson" <aemerson@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

On 11/02/2016, Gregory Farnum wrote:
> So if I'm reading the samples changes here correctly, we seem to have
> a bunch of new warnings around the lock changes? Is this something we
> should be resolving in the lock users, or whitelisting, or fixing
> lower down in the stack?

In this case:

> > 320           return tu;
> > 321         } else if (m == nullptr) {
> > 322           return unique_lock_type();
> > 323         }
> > 324         throw std::system_error((int)std::errc::operation_not_permitted,
> > 325                                 std::generic_category());
> >>>>     CID 1352097:  Control flow issues  (UNREACHABLE)
> >>>>     This code cannot be reached: "return ceph::shunique_lock<...".
> > 326         return unique_lock_type();
> > 327       }

This is harmless. It's true that it won't ever be reached, but the function has
a return type and so has to return something. I could rewrite it so we check for
the error case explicitly and fail then and return something in the non-marked
case, but as a matter of good design I think it's better in cases like this to
explicitly handle the /good/ cases and fail on everything else.

> >>>>     CID 1352096:    (UNCAUGHT_EXCEPT)
> >>>>     In function "main(int, char **)" an exception of type "boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::ios_base::failure> >" is thrown and never caught.

This is just something in the Boost library. The standard library's
shared_lock will throw an exception under similar circumstances. It's not
really an issue since they only get thrown on things like calling lock
on a unique_ or shared_lock that already owns a lock. Things that you
can rule out fairly easily by how you write a function but the compiler
can't check them for you (unless we rewrite Ceph in Rust.)

I think this one ought to be whitelisted since it's an issue in the library that
will only end up with terminate being called if there's a seriosu bug in the
program. (The kind of thing that really /ought/ to make it crash.)

-- 
Senior Software Engineer           Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC, Freenode}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C  7C12 80F7 544B 90ED BFB9

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 603 bytes --]