Re: Coverity Open Source Defect Scan of PostgreSQL

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: ben(at)coverity(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Coverity Open Source Defect Scan of PostgreSQL
Date: 2006-03-09 10:03:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Mar 08, 2006 at 06:42:45PM -0500, Greg Stark wrote:
> Ben Chelf <ben(at)coverity(dot)com> writes:
> > >>>#ifdef STATIC_ANALYSIS
> > >>>#define ereport(elevel, rest) \
> > >>> (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \
> > >>> (errfinish rest) : (void) 0), (elevel >= ERROR ? exit(0) : 0)
> > >>>#else
> > >>>/* Normal def */
> > >>>#endif
> >
> > As for Coverity, if the elevel that's passed to the ereport is really a
> > constant, the above #ifdef should absolutely do the trick for us so we know to
> > stop analyzing on that path...Let me know if it doesn't actually do that ;)
> If you're willing to require elevel to always be a constant then why not just
> tack on the (elevel >= ERROR ? exit(0) : 0) onto the end of the regular
> definition of ereport instead of having an ifdef?

Well, the only cost would be a useless call to exit() for each
elog/ereport with an elevel >= ERROR. It bloats the binary a bit. Not
sure whether people care enough about that.

Have a nice day,
Martijn van Oosterhout <kleptog(at)svana(dot)org>
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-03-09 10:08:07 Re: [COMMITTERS] pgsql: Remove Christof Petig copyright on include file,
Previous Message Zeugswetter Andreas DCP SD 2006-03-09 09:56:26 Re: Merge algorithms for large numbers of "tapes"