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

From Tom Lane
Subject Re: Coverity Open Source Defect Scan of PostgreSQL
Date
Msg-id 27339.1141936317@sss.pgh.pa.us
Whole thread Raw
In response to Re: Coverity Open Source Defect Scan of PostgreSQL  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: Coverity Open Source Defect Scan of PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Coverity Open Source Defect Scan of PostgreSQL  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> Why?  I don't think we are able to run 'embedded' now as it is, so its not 
> like we're dealign with system with small disk spaces :)  how much bigger 
> would adding that exit() make the binary?

It's not only the exit(), as the elevel parameter isn't always a
constant.  The proposed patch would at a minimum expose us to
double-evaluation risks.  I kinda doubt there are any cases where an
elevel parameter expression has side-effects, so that objection may be
mostly hypothetical, but nonetheless we are talking about more than just
wasting a few bytes.  It's not impossible that the patch would introduce
outright bugs.  Consider something like
/* ENOENT is expected, anything else is not */elog(errno == ENOENT ? DEBUG : ERROR, ...)

By the time control comes back from elog, errno would likely be
different, and so this would result in an unexpected exit() call
if the patch is in place.  I'd be the first to call the above poor
coding, but it wouldn't be a bug ... unless the errno is rechecked.

It's been asserted that Coverity can be taught to understand about
elog/ereport without this sort of hack, so I'd rather take that tack.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Coverity Open Source Defect Scan of PostgreSQL
Next
From: Bruce Momjian
Date:
Subject: Re: Coverity Open Source Defect Scan of PostgreSQL