Re: An confusing Coverity issue in regcomp.c

[Bruno Haible]

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