Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Wed, Mar 08, 2006 at 10:34:38PM -0800, Ben Chelf wrote: > On 3/8/06, Josh Berkus wrote: > > >Actually, I thougth that Neil/eDB did this with their copy. Is > > there any way to get a copy of that "training configuration"? > > > Just to jump in on this thread, we can absolutely configure

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On 3/8/06, Josh Berkus wrote: >Actually, I thougth that Neil/eDB did this with their copy. Is > there any way to get a copy of that "training configuration"? Just to jump in on this thread, we can absolutely configure elog -- if you have the config already, great. If not, if you can just

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Thu, 9 Mar 2006, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> 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 e

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

* Bruce Momjian (pgman@candle.pha.pa.us) wrote: > > 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. > > Agreed. The idea of modifying our binary in any way to help a sanity > tool not complain is totally

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> 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()

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

"Marc G. Fournier" <[EMAIL PROTECTED]> 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 is

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Thu, 9 Mar 2006, Bruce Momjian wrote: Martijn van Oosterhout wrote: -- Start of PGP signed section. On Wed, Mar 08, 2006 at 06:42:45PM -0500, Greg Stark wrote: Ben Chelf <[EMAIL PROTECTED]> writes: #ifdef STATIC_ANALYSIS #define ereport(elevel, rest) \ (errstart(elevel, __FILE__,

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Wed, Mar 08, 2006 at 06:42:45PM -0500, Greg Stark wrote: > > Ben Chelf <[EMAIL PROTECTED]> writes: > > > > > >>>#ifdef STATIC_ANALYSIS > > > >>>#define ereport(elevel, rest) \ > > > >>>(errstart(elevel, __FILE__, __LINE__,

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Wed, Mar 08, 2006 at 06:42:45PM -0500, Greg Stark wrote: > Ben Chelf <[EMAIL PROTECTED]> writes: > > > >>>#ifdef STATIC_ANALYSIS > > >>>#define ereport(elevel, rest) \ > > >>>(errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \ > > >>> (errfinish rest) : (void) 0), (ele

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Ben Chelf <[EMAIL PROTECTED]> 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

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On 3/8/06, Josh Berkus wrote: Actually, I thougth that Neil/eDB did this with their copy.  Is there anyway to get a copy of that "training configuration"? I think we have a backup of it somewhere.  I'll look into it. -- Jonah H. Harris, Database Internals ArchitectEnterpriseDB

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Folks, > 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 ;) Um, I think the answer is to train Coverity, not change

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Martijn van Oosterhout wrote: On Tue, Mar 07, 2006 at 05:39:18PM -0500, Tom Lane wrote: Martijn van Oosterhout writes: #ifdef STATIC_ANALYSIS #define ereport(elevel, rest) \ (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \ (errfinish rest) : (void) 0), (elevel >

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Tue, Mar 07, 2006 at 05:39:18PM -0500, Tom Lane wrote: > Martijn van Oosterhout writes: > > #ifdef STATIC_ANALYSIS > > #define ereport(elevel, rest) \ > > (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \ > > (errfinish rest) : (void) 0), (elevel >= ERROR ? exit(0)

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Martijn van Oosterhout 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 Hmm, neat idea ... though

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Tue, Mar 07, 2006 at 05:10:44PM -0500, Greg Stark wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> 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 > Postgr

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Alvaro Herrera <[EMAIL PROTECTED]> 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 do

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Neil Conway wrote: > I'm a bit surprised to see that there are ~300 unfixed defects: AFAIR I > fixed all the issues the EDB guys passed on to me, with the exception of > some false positives and a handful of minor issues in ECPG that I > couldn't be bothered fixing (frankly I would rather not touc

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Mon, Mar 06, 2006 at 12:50:15PM -0400, Marc G. Fournier wrote: > >I thought we ran the Converity analysis a year ago and cleaned up the > >warnings, so I am surprised at our high number, but I assume they are > >mostly noise. > > Got an account and will take a look at the details this evening .

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Ben, >I'm the CTO of Coverity, Inc., a company that does static source code > analysis to look for defects in code. You may have heard of us or of our > technology from its days at Stanford (the "Stanford Checker"). The > reason I'm writing is because we have set up a framework internally to >

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Neil Conway wrote: On Mon, 2006-03-06 at 11:55 -0300, Alvaro Herrera wrote: AFAIR they got a private scan done and they fixed the reported defects. Indeed: EnterpriseDB paid for a license for the Coverity static analysis tool, and then ran that tool on the open-source Postgres tree. O

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Mon, 2006-03-06 at 11:55 -0300, Alvaro Herrera wrote: > AFAIR they got a private scan done and they fixed the reported defects. Indeed: EnterpriseDB paid for a license for the Coverity static analysis tool, and then ran that tool on the open-source Postgres tree. One of their engineers then wor

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Mon, 6 Mar 2006, Bruce Momjian wrote: Andreas Pflug wrote: Ben Chelf wrote: Hello PostgreSQL Developers, I'm the CTO of Coverity, Inc., a company that does static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (th

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

OTOH neither JBoss, BerkeleyDB, Qt are listed. Is there a pattern here? http://www.coverity.com/news/news_02_15_05_story_6.html ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Alvaro Herrera wrote: AFAIR they got a private scan done and they fixed the reported defects. After that they issued a press release telling how little defects they got, or something ... OTOH neither JBoss, BerkeleyDB, Qt are listed. Is there a pattern here? I guess the pattern is obvious in

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Andreas Pflug wrote: > Ben Chelf wrote: > >Hello PostgreSQL Developers, > > > > I'm the CTO of Coverity, Inc., a company that does static source code > >analysis to look for defects in code. You may have heard of us or of our > >technology from its days at Stanford (the "Stanford Checker"). The

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Andreas Pflug wrote: > Ben Chelf wrote: > > Hello PostgreSQL Developers, > > > > I'm the CTO of Coverity, Inc., a company that does static source code > > analysis to look for defects in code. You may have heard of us or of our > > technology from its days at Stanford (the "Stanford Checker").

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Ben Chelf wrote: Hello PostgreSQL Developers, I'm the CTO of Coverity, Inc., a company that does static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we ha

[HACKERS] Coverity Open Source Defect Scan of PostgreSQL

Hello PostgreSQL Developers, I'm the CTO of Coverity, Inc., a company that does static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framew