On Fri, Feb 23, 2018 at 05:40:23PM -0600, Jason L Tibbitts III wrote:
> It creates various search indices for the IMAP server (which is why it
> wraps Xapian).  The manpage is available from
> https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html
> Technically the test suite simply creates the conditions for it to do
> its work (in a randomly named directory) and then calls squatter
> directly.  You should be able to see the arguments in the test suite's
> output.

Ok, so the problem is ignoring important warnings, in this case:
imap/xapian_wrap.cpp: In function 'int 
stem_version_set(Xapian::WritableDatabase*, int)':
imap/xapian_wrap.cpp:267:1: warning: no return statement in function returning 
non-void [-Wreturn-type]

Don't do that, especially not for C++.  While for C there is UB only if you
actually use the returned value that hasn't been returned, i.e. in the
caller, and if you never use the return value, nothing bad happens,
in C++ the UB happens already in the callee, so the compiler in:
static int stem_version_set(Xapian::WritableDatabase *database, int version)
{
    std::ostringstream convert;
    convert << version;
    database->set_metadata(XAPIAN_STEM_VERSION_KEY, convert.str());
}
can (and does) assume that if this function is called, then it will never
fall-through from the last call into following code, because that is UB,
even when the caller is doing just:
stem_version_set(dbw->database, dbw->stem_version);

Didn't have time to try that, but I think -fsanitize=undefined should have
diagnosed that too in addition to the warning.  And the effect in the
generated code is just that there is no edge from that set_metdata method
call to anything that follows it, so the call is followed by whatever other
code happened to be emitted next, in this case some C++ EH code that ends
with _Unwind_Resume and assumed it is invoked only when throwing or
rethrowing an exception.

So, effective summary, in C++ >>NEVER<< ignore -Wreturn-type warning.

        Jakub
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to