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
