Re: An confusing Coverity issue in regcomp.c

[Darren Kenny]

Thanks Bruno for confirming - certainly was confusing :) 

Thanks,

Darren.

On Thursday, 2022-03-24 at 20:34:45 +01, Bruno Haible wrote:
> Hi Darren,
>
> I appreciate that you are, like Paul and me, looking into the
> Coverity findings.
>
> You need to be aware that about 90% of the Coverity findings are
>   - either irrelevant (for example, complaints about passing
>     negative file descriptors to system calls in the test suite),
>   - or false positives (due to Coverity limitations, for example,
>     Coverity does not distinguish foo->bar[0].x and foo->bar[1].x).
>
> In order to use Coverity efficiently, we therefore need to find
> the relevant findings quickly, and spend as little time as possible
> on the false positives.
>
>> While running Coverity on this code, I'm seeing the following error
>> where Coverity believes that the return value from re_compile_internal()
>> may contain a value between -1 and 31.
>
> I looked at it too, and after 15 seconds I came to the same conclusion
> as you:
>
>> the return value is a
>> reg_errcode_t enumeration - which for most cases has integer values in
>> the range 0 to 17. (more below on that).
>
> So, it's a false positive. End of story.
>
> We don't modify our source-code, to placate Coverity. Coverity has its
> own mechanism for eliminating false positives, namely an (unfortunately)
> SaaS web UI.
>
>> Should the code ensure that this could never happen by only ever
>> defining the -1 value with those above defines in place
>
> IMHO, the comment regarding _REG_ENOSYS is sufficient.
>
> Bruno