New Defects reported by Coverity Scan for LibreOffice
Stephan Bergmann
sbergman at redhat.com
Thu Feb 2 08:00:54 UTC 2023
On 01/02/2023 23:24, Kohei Yoshida wrote:
> On 01.02.2023 02:31, Stephan Bergmann wrote:
>> On 01/02/2023 02:37, Kohei Yoshida wrote:
>>> I just borrowed your solution and called it "resolved", though I
>>> believe, even without that explicit try catch block, it would just
>>> terminate all the same?
>>
>> Yes. But without the explicit try catch block it would help compiler
>> runtimes report the place where the (effectively uncaught, and
>> presumably "this can't happen"-style unexpected) exception was
>> actually thrown. I'm not convinced Coverity Scan is doing us a
>> service here, overall.
>
> Gotcha. Thinking about this a bit, maybe it's better not to have that
> explicit try catch block I just added. Let me know what you all think.
I assume that this is actually a false positive, i.e., that while
delete_element_blocks can throw in general, it is guaranteed that it
will never throw in that invocation from within ~multi_type_vector.
Otherwise, it wouldn't be sound to introduce the try/catch/terminate
here anyway. Isn't there a way to mark that false positive with an
appropriate Coverity Scan comment?
More information about the LibreOffice
mailing list