Re: Coverity Open Source Defect Scan of PostgreSQL - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Coverity Open Source Defect Scan of PostgreSQL
Date
Msg-id 87ek1doqhn.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Coverity Open Source Defect Scan of PostgreSQL  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Coverity Open Source Defect Scan of PostgreSQL
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:

> but they do make the mistake of not noticing that ereport(ERROR)
> does not continue execution. 

There is a way in gcc to indicate that a function never returns. But in
Postgres it's a bit weird since elog()/ereport() sometimes return and
sometimes don't. Perhaps it would be better to make the forms that don't
return separate functions. Then hopefully they can be marked to not trigger
these kinds of warnings.

> We all know that this is not a bug.  There are lots of these, as you can
> imagine.  
> 
> There are lots of other "not a bugs".  For example in initdb, there is a
> lot of noise about how we don't free the resources.

Presumably the reason they don't immediately release the reports is for fear
of security holes revealed. Once somebody has checked the errors and checked
for any exploitable holes would it be possible to just open access to anyone
so mere mortals can clean up the mundane bugs?

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: problem with large maintenance_work_mem settings and
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Coverity Open Source Defect Scan of PostgreSQL