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
