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