From acacio.centeno at terra.com.br Fri Jul 2 13:46:21 2010 From: acacio.centeno at terra.com.br (=?iso-8859-1?Q?Ac=E1cio_Centeno?=) Date: Fri, 2 Jul 2010 14:46:21 -0300 Subject: [splint-discuss] Semantics of /*@temp@*/ Message-ID: <009301cb1a0e$7ca3e050$75eba0f0$@centeno@terra.com.br> Hello, I?m reading splint manual and it defines temp annotation as: ?The temp annotation is used to declare a function parameter that is used temporarily by the function. An error is reported if the function releases the storage associated with a temp formal parameter or creates new aliases to it that are visible after the function returns. Any storage may be passed as a temp parameter, and it satisfies its original memory constraints after the function returns.? However, I?ve put up this code snippet to test it, and, it seems to me that splint should be complaining about the assignment of ?i? to ?global?, as I?m creating an alias that is visible outside of func1(). Am I getting it wrong? When func2() executes, it effectivelly writes to freed memory. #include #include static int /*@null@*/ *global = NULL; static void func1(int /*@temp@*//*@null@*/ *i) { if(i) *i=2; global = i; } static void func2(void) { if(global) *global = 3; } int main(void) { /*@only@*/ int *i; i = (int *) malloc(sizeof(int)); if ( i ) { *i = 0; func1(i); free(i); func2(); } return 0; } Thanks in advance, Ac?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20100702/40e7e9b7/attachment.html From girish.adiga at oracle.com Fri Jul 2 13:50:55 2010 From: girish.adiga at oracle.com (girish.adiga at oracle.com) Date: Fri, 2 Jul 2010 10:50:55 -0700 (PDT) Subject: [splint-discuss] Auto Reply: Semantics of /*@temp@*/ Message-ID: <89307343-ef9a-478a-bb20-d6d417b3d84d@default> I'm on vacation till 6th Jul. Please contact my manager eric.wang at oracle.com for any urgent issues. From splint at sympatico.ca Sun Jul 4 21:24:31 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Sun, 04 Jul 2010 21:24:31 -0400 Subject: [splint-discuss] Semantics of /*@temp@*/ In-Reply-To: <009301cb1a0e$7ca3e050$75eba0f0$@centeno@terra.com.br> (=?iso-8859-1?Q?Ac=E1cio?= Centeno's message of "Fri, 2 Jul 2010 14:46:21 -0300") References: <009301cb1a0e$7ca3e050$75eba0f0$@centeno@terra.com.br> Message-ID: On 2 Jul 2010, acacio.centeno at terra.com.br wrote: > However, I've put up this code snippet to test it, and, it > seems to me that splint should be complaining about the assignment of "i" > to "global", as I'm creating an alias that is visible outside of func1(). > Am I getting it wrong? Splint will not find every problem out of the box. You must do some work to get it to check what you wish. Global variables are particularly bad idea unless you have taken great care to think about them. That is why you should have a known interface in how they are being used. This is also most helpful to other programmers as they don't have to grep the source to find every instance of where and how the variable is used. Short answer, follow this to it's conclusion. - static int /*@null@*/ *global = NULL; + static int /*@null@*/ /*@checkedstrict@*/ *global = NULL; See section 7.2, 7.3, etc. To find these things automatically takes a lot of CPU as you must analyze the whole program. The case you cite is very simple for a human to understand, but it is not so easy to understand the general case which a program checker should do. So splint's design requires you annotate your source. hth, Bill Pringlemeir. -- Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED! From girish.adiga at oracle.com Sun Jul 4 21:26:36 2010 From: girish.adiga at oracle.com (girish.adiga at oracle.com) Date: Sun, 4 Jul 2010 18:26:36 -0700 (PDT) Subject: [splint-discuss] Auto Reply: Re: Semantics of /*@temp@*/ Message-ID: <75cd87c1-f60c-4d18-81e8-8b2df0475c81@default> I'm on vacation till 6th Jul. Please contact my manager eric.wang at oracle.com for any urgent issues. From francesco.giuliani at mermecgroup.com Tue Jul 6 06:39:12 2010 From: francesco.giuliani at mermecgroup.com (Giuliani Francesco) Date: Tue, 6 Jul 2010 12:39:12 +0200 Subject: [splint-discuss] How to skip assembler statements during splint compile Message-ID: Hi all, I've just to know how is possible to skip assembler statements during splint compile, I just try with compile flags (like #define S_SPLINT_S) but I want to know how is possible to it automatically using the parse flags build-in Splint. Thanks in advances, fg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20100706/1ed28a5a/attachment.html From girish.adiga at oracle.com Tue Jul 6 06:51:22 2010 From: girish.adiga at oracle.com (girish.adiga at oracle.com) Date: Tue, 6 Jul 2010 03:51:22 -0700 (PDT) Subject: [splint-discuss] Auto Reply: How to skip assembler statements during splint compile Message-ID: <66896df5-1bde-49fd-9e21-009830d81948@default> I'm on vacation till 6th Jul. Please contact my manager eric.wang at oracle.com for any urgent issues. From splint at sympatico.ca Tue Jul 6 13:22:20 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Tue, 06 Jul 2010 13:22:20 -0400 Subject: [splint-discuss] How to skip assembler statements during splint compile In-Reply-To: (Giuliani Francesco's message of "Tue, 6 Jul 2010 12:39:12 +0200") References: Message-ID: On 6 Jul 2010, francesco.giuliani at mermecgroup.com wrote: > I've just to know how is possible to skip assembler statements during > splint compile, I just try with compile flags (like #define S_SPLINT_S) > but I want to know how is possible to it automatically using the parse > flags build-in Splint. You can define '__asm__' or whatever your inline assembler is to be something else that the parser will ignore. This is often difficult and it has the bad side effect that splint will think values are not modified when they are as it has no idea what happened in the assembler statement as may some other programmers. It can be beneficial to provide semantically equivalent code in the alternate condition for splint to parse. I may help people not familiar with the assembler variant. /* fast exclusive or. */ #ifdef S_SPLINT_S for(p=start; p != end; p++) sum ^= *p; #else __asm__("1: cmp %0,%2\n" " xorne %0,%1\n" " bne 1", sum, p, end); /* This assembler is non-sense in the hope that you might grok that not every one groks. */ #endif If you are checking a 3rd party source, then I suggest you isolate the assembler as best as possible and not check those functions. You can still provide good annotations of them to verify callers. You might also try to google this mailing list archive. http://www.google.ca/#q=site%3Awww.cs.virginia.edu+%22splint-discuss%22+inline+assembler+-Digest hth, Bill Pringlemeir. -- Keep an open mind. But not so open your brains fall out. - Kallis' Law From skye at fll-freak.com Tue Jul 6 17:01:33 2010 From: skye at fll-freak.com (Skye Sweeney) Date: Tue, 6 Jul 2010 17:01:33 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 Message-ID: I am looking for an annotated header file for sqlite3. If someone has done this work already I would love to piggyback on your sweat. If not, I will be working on this and could post it back to the group. PS: Is there a repository of annotated vendor include files someplace? I was not able to find one if it exists. -- -Skye Sweeney -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20100706/834eb4b6/attachment.html From n3npq at mac.com Tue Jul 6 18:35:09 2010 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 06 Jul 2010 18:35:09 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: References: Message-ID: On Jul 6, 2010, at 5:01 PM, Skye Sweeney wrote: > I am looking for an annotated header file for sqlite3. If someone has done this work already I would love to piggyback on your sweat. If not, I will be working on this and could post it back to the group. > > PS: Is there a repository of annotated vendor include files someplace? I was not able to find one if it exists. > I likely did splint annotations for sqlite3 4-5 years ago. You can likely find in a top level check-out from cvs -d :ext:rpm-cvs at rpm5.org:/v/rpm/cvs get sqlite Lemme look ... yeah there's a top-level module called "sqlite" still. Please note "... 4-5 years ago ..." These days I use the sqlite3 in db-5.0.21. hth 73 de Jeff From splint at sympatico.ca Wed Jul 7 12:32:41 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 07 Jul 2010 12:32:41 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: (Jeff Johnson's message of "Tue, 06 Jul 2010 18:35:09 -0400") References: Message-ID: On 6 Jul 2010, n3npq at mac.com wrote: On Jul 6, 2010, at 5:01 PM, Skye Sweeney wrote: >> PS: Is there a repository of annotated vendor include files someplace? I was >> not able to find one if it exists. > I likely did splint annotations for sqlite3 4-5 years ago. I can add it to the splint 'lib' directory if you believe that is feasible. You can run the command, splint -nof -nolib +impconj sqlite.h -dump sqlite Then you can check the file with '-load sqlite'. The annotated header would have to be completely independent of the sql distribution. I would add it to the 'lib' makefile and can add a small test as well to the 'test' directory if you believe that would be helpful somehow. If this is too difficult, I can add a contrib directory and just provide the un-processed header. fwiw, Bill Pringlemeir. -- Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED! From n3npq at mac.com Wed Jul 7 12:46:43 2010 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 07 Jul 2010 12:46:43 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: References: Message-ID: <93F9200D-86C5-4F73-8F0E-C51186406E58@mac.com> On Jul 7, 2010, at 12:32 PM, Bill Pringlemeir wrote: > On 6 Jul 2010, n3npq at mac.com wrote: > > On Jul 6, 2010, at 5:01 PM, Skye Sweeney wrote: > >>> PS: Is there a repository of annotated vendor include files someplace? I was >>> not able to find one if it exists. > > >> I likely did splint annotations for sqlite3 4-5 years ago. > > I can add it to the splint 'lib' directory if you believe that is > feasible. You can run the command, > > splint -nof -nolib +impconj sqlite.h -dump sqlite > > Then you can check the file with '-load sqlite'. The annotated header > would have to be completely independent of the sql distribution. > > I would add it to the 'lib' makefile and can add a small test as well > to the 'test' directory if you believe that would be helpful somehow. > If this is too difficult, I can add a contrib directory and just > provide the un-processed header. > Oooh nice! I have a fair number of projects splint annotated if interested: neon gcrypt beecrypt gnutls sqlite elfutils rsync all used with RPM/POPT (which are also completely splint annotated). I've likely got half a dozen more projects around somewhere too, I have used splint quite heavily in the past. (aside) These days I find LLVM and coverity easier to maintain even if custom splint annotations are likely as accurate as one wishes, depending on the level of detail one desires). I might be able to find some time to dig out API (in *.h only) which is (my guess, not looked) what you are attempting with "-load sqlite". hth 73 de Jeff From skye at fll-freak.com Thu Jul 8 08:36:52 2010 From: skye at fll-freak.com (Skye Sweeney) Date: Thu, 8 Jul 2010 08:36:52 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 Message-ID: Sorry to have taken so long to reply. I signed up for the Digest form and between that and my work schedule (work always seems to get in the way of fun things) time got away. Jeff Johnson, I would very much like to get my hands on your SQLITE3 annotated H file. If at all possible I would also like to get the original H file as well. With the original I can diff it against the new version and then push the relevant changes into your annotated file. I am not aware of a file upload mechanism here, so I would ask that you email them to me at Skye at fll-freak.com. Bill Pringlemeir, If I get the work done to a reasonable level I would be happy to send the results to you to include in a future release. As for other annotated headers that Jeff referred to, perhaps an addition to the SPLINT website that would serve as a repository for 3rd party work might be in order. Perhaps as a wiki? -- -Skye Sweeney -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20100708/3e8bc7bc/attachment.html From splint at sympatico.ca Fri Jul 9 08:37:48 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Fri, 09 Jul 2010 08:37:48 -0400 Subject: [splint-discuss] Annotated headers/interface for open source project [was: Annotated header for SQLITE3] In-Reply-To: <93F9200D-86C5-4F73-8F0E-C51186406E58@mac.com> (Jeff Johnson's message of "Wed, 07 Jul 2010 12:46:43 -0400") References: <93F9200D-86C5-4F73-8F0E-C51186406E58@mac.com> Message-ID: On Jul 7, 2010, at 12:32 PM, Bill Pringlemeir wrote: > I would add it to the 'lib' makefile and can add a small test as > well to the 'test' directory if you believe that would be helpful > somehow. If this is too difficult, I can add a contrib directory > and just provide the un-processed header. On 7 Jul 2010, n3npq at mac.com wrote: > Oooh nice! > I have a fair number of projects splint annotated if interested: > neon > gcrypt > beecrypt > gnutls > sqlite > elfutils > rsync > all used with RPM/POPT (which are also completely splint annotated). > I've likely got half a dozen more projects around somewhere too, > I have used splint quite heavily in the past. If you can provide access via cvs, etc I can grab the files and put them in a contrib directory. I have a project that I use splint and gnutls with. I might consider using that as a test case to see about making them into 'pre-processed' libraries. > (aside) > These days I find LLVM and coverity easier to maintain even > if custom splint annotations are likely as accurate as > one wishes, depending on the level of detail one desires). > I might be able to find some time to dig out API (in *.h only) which > is (my guess, not looked) what you are attempting with "-load sqlite". If you make them available (or more widely known), then more people may be motivated to do this work. Regards, Bill Pringlemeir. -- It isn't premarital sex if you have no intention of getting married. - Matt Barry From splint at sympatico.ca Fri Jul 9 09:07:32 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Fri, 09 Jul 2010 09:07:32 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: (Jeff Johnson's message of "Tue, 06 Jul 2010 18:35:09 -0400") References: Message-ID: On 6 Jul 2010, n3npq at mac.com wrote: On Jul 6, 2010, at 5:01 PM, Skye Sweeney wrote: >> I am looking for an annotated header file for sqlite3. If someone has done >> this work already I would love to piggyback on your sweat. If not, I >> will be working on this and could post it back to the group. > I likely did splint annotations for sqlite3 4-5 years ago. > You can likely find in a top level check-out from > cvs -d :ext:rpm-cvs at rpm5.org:/v/rpm/cvs get sqlite > Lemme look ... yeah there's a top-level module called "sqlite" still. > Please note "... 4-5 years ago ..." These days I use the sqlite3 in db-5.0.21. I tried this. There is a '.splintrc' file for processing the 'sqlite' project, but there are no annotations that I can discern in this project. bpringle at pvr:/home/src/sqlite$ cat CVS/Root :pserver:anonymous at rpm5.org:/v/rpm/cvs Is this the correct project? Thanks, Bill Pringlemeir. From n3npq at mac.com Fri Jul 9 09:26:24 2010 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 09 Jul 2010 09:26:24 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: References: Message-ID: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> On Jul 9, 2010, at 9:07 AM, Bill Pringlemeir wrote: > On 6 Jul 2010, n3npq at mac.com wrote: > On Jul 6, 2010, at 5:01 PM, Skye Sweeney wrote: > >>> I am looking for an annotated header file for sqlite3. If someone has done >>> this work already I would love to piggyback on your sweat. If not, I >>> will be working on this and could post it back to the group. > >> I likely did splint annotations for sqlite3 4-5 years ago. > >> You can likely find in a top level check-out from >> cvs -d :ext:rpm-cvs at rpm5.org:/v/rpm/cvs get sqlite > >> Lemme look ... yeah there's a top-level module called "sqlite" still. > >> Please note "... 4-5 years ago ..." These days I use the sqlite3 in db-5.0.21. > I tried this. There is a '.splintrc' file for processing the 'sqlite' project, but there are no annotations that I can discern in this project. > > bpringle at pvr:/home/src/sqlite$ cat CVS/Root > :pserver:anonymous at rpm5.org:/v/rpm/cvs > > Is this the correct project? > Yes. Apologies for misinformation (I did the annotations years ago). Let me find where splint anotations got buried (its likely a branch/check-in deep inside the repository). If I can't find the annotations, I'll re-annotate (sqlite3 is embedded in RPM these days, so it will only take me a few hours to annotate the API in sqlite3.h) and send along. Actually modern annotations are likely more useful than anything I did before (though sqlite3's API hardly ever changes). Again apologies for the misinformation. I'm very happy to hear that splint is including annotated headers. 73 de Jeff From splint at sympatico.ca Fri Jul 9 10:24:41 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Fri, 09 Jul 2010 10:24:41 -0400 Subject: [splint-discuss] Parse Error on variable declaration inthe middleof a function. In-Reply-To: (Jake Holland's message of "Mon, 23 Mar 2009 10:32:20 -0700") References: <49C4D1A6.10206@fun-tech.se> <11352F9641010A418AD5057945A3A6590118BD3C@MTV-EXCHANGE.microfocus.com> <49C505A3.5020504@fun-tech.se> <11352F9641010A418AD5057945A3A6590118BD42@MTV-EXCHANGE.microfocus.com> Message-ID: On 23 Mar 2009, JHolland at fastsoft.com wrote: > This email has a patch attached for OP's problem: > http://www.cs.virginia.edu/pipermail/splint-discuss/2008-July/001190.html I recently update CVS with this change (C99 style declarations mixed with statements). Thanks, Bill Pringlemeir. -- Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED! From n3npq at mac.com Fri Jul 9 12:31:54 2010 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 09 Jul 2010 12:31:54 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> References: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> Message-ID: <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> On Jul 9, 2010, at 9:26 AM, Jeff Johnson wrote: >> >> Is this the correct project? >> > I have a check-out from sourceforge cvs installed in order to re-annotate sqlite3.h API. Is there an example for how you are intending to include additional API's like sqlite3 in splint? Off hand, I don't see additional API modules in /usr/share/splint/{imports,lib}/* (my guess, perhaps wrong, at how you are intending to include additional annotated API's). What am I missing? Any example of the annotation style you wish in splint will assist me. I can likely read an annotation example faster than any other description of what you want. 73 de Jeff From splint at sympatico.ca Fri Jul 9 13:06:57 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Fri, 09 Jul 2010 13:06:57 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> (Jeff Johnson's message of "Fri, 09 Jul 2010 12:31:54 -0400") References: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> Message-ID: On 9 Jul 2010, n3npq at mac.com wrote: > I have a check-out from sourceforge cvs installed in order to > re-annotate sqlite3.h API. > Is there an example for how you are intending to include additional > API's like sqlite3 in splint? The 'lib' directory has several headers and a Makefile. This is the gist of what I am proposing. Chapter 14 of the manual is a fairly quick read (with 14.2/14.3 probably the most important). I don't mean to make work for you. Any annotation you can provide are fine. I am sure it is fairly easy to remove troublesome constructs. The question is whether the annotate file is sufficient to parse all 'user' source or does the original release file also have to be parsed to get some needed symbols and/or macros. Thanks again, Bill Pringlemeir. -- It isn't premarital sex if you have no intention of getting married. - Matt Barry From n3npq at mac.com Fri Jul 9 13:10:06 2010 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 09 Jul 2010 13:10:06 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: References: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> Message-ID: On Jul 9, 2010, at 1:06 PM, Bill Pringlemeir wrote: > On 9 Jul 2010, n3npq at mac.com wrote: > >> I have a check-out from sourceforge cvs installed in order to >> re-annotate sqlite3.h API. > >> Is there an example for how you are intending to include additional >> API's like sqlite3 in splint? > > The 'lib' directory has several headers and a Makefile. This is the > gist of what I am proposing. Chapter 14 of the manual is a fairly > quick read (with 14.2/14.3 probably the most important). > Thanks. Off to look ... > I don't mean to make work for you. Any annotation you can provide are > fine. I am sure it is fairly easy to remove troublesome constructs. > The question is whether the annotate file is sufficient to parse all > 'user' source or does the original release file also have to be parsed > to get some needed symbols and/or macros. > No work, applying splint annotations takes practice, I'm rusty, use it or lose it. I don't mind a bit ... 73 de Jeff From splint at sympatico.ca Fri Jul 9 13:45:30 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Fri, 09 Jul 2010 13:45:30 -0400 Subject: [splint-discuss] string concatenation patch In-Reply-To: <477BC14A.70600@mindspring.com> (Ed Beroset's message of "Wed, 02 Jan 2008 11:52:26 -0500") References: <47790224.1020108@mindspring.com> <20080102155408.GA4078@static-81.216.50.98.addr.tdcsong.se> <477BC14A.70600@mindspring.com> Message-ID: Tommy Pettersson wrote: > On Mon, Dec 31, 2007 at 09:52:20AM -0500, Ed Beroset wrote: >> + case '\\': >> + *ss++ = *ts++; >> + escape = TRUE; >> + /*@switchbreak@*/ break; > > I think this code will mess up an escaped backslash, e.g., > > "foo \\" FOOBAR " bar" On 2 Jan 2008, beroset at mindspring.com wrote: > You're right. Thanks for the bug report. I'll fix that. Did you ever fix this? I have your original set. I have some other fixes pending, but if you haven't done anything with this, I can add it to my list. Here are the CVS changes from 3.1.2. The enchancements have been recent additions. If anyone is using the 3.1.2 release actively, regressions with the CVS version would be appreciated. (Ie, any differences between 'splint-cvs' and 'splint-3_1_2'). Enhancements ============ * support for 'hh' printf modifier. Walter Goossens * support for gcc VAR_ARGS variable macro token. Bernhard R. Link * support for C99 mixed statment declarations. Jake Holland Bugs ==== 2487422 1837229 Fix build on Apple platforms. +others (which were enhancements). File changelogs =============== Add batch from Debian/Bernhard R. Link. Also added check for +gnuextentions. Add support for the hh modifier in printf and scanf like functions. Closes bugID 2487422 Allow compile on apple platforms. osd.c Use pid_t instead of __pid_t as per open group. Changed makefile to include line information in generated yacc/bison code (as I had already commited the 'der' variants. Convert some llassert() to llassertfatal(), as we should not continue with null pointers. Fix bit rot of DPRINTF calls. Fix debug Fix tracker issue 1837229. Synopsis: return +1; The XPR_PREOP case treats plus/minus the same now. I don't grok how unary values are being handled in splint, but at least +/- are the same. Fixed the OS/2 specific files for the latest release. Remove unused cpplib_createDefinition. Removed if statement with constant results Update configure and makefile to aclocal/automake 1.10.1 and autoconf 2.61. Update grammar with changes from Jake Holland (JHolland at FASTSOFT.COM). Also removed '#line' items from the generated bison files. Update test files to automake 1.10.1 noexpand always false. From n3npq at mac.com Sat Jul 10 16:46:45 2010 From: n3npq at mac.com (Jeff Johnson) Date: Sat, 10 Jul 2010 16:46:45 -0400 Subject: [splint-discuss] Annotated header for SQLITE3 In-Reply-To: References: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> Message-ID: <76B1E4ED-4E38-4213-8205-7AC724AC74A1@mac.com> On Jul 9, 2010, at 1:10 PM, Jeff Johnson wrote: > > On Jul 9, 2010, at 1:06 PM, Bill Pringlemeir wrote: > >> On 9 Jul 2010, n3npq at mac.com wrote: >> >>> I have a check-out from sourceforge cvs installed in order to >>> re-annotate sqlite3.h API. >> >>> Is there an example for how you are intending to include additional >>> API's like sqlite3 in splint? >> >> The 'lib' directory has several headers and a Makefile. This is the >> gist of what I am proposing. Chapter 14 of the manual is a fairly >> quick read (with 14.2/14.3 probably the most important). >> > > Thanks. Off to look ... > >> I don't mean to make work for you. Any annotation you can provide are >> fine. I am sure it is fairly easy to remove troublesome constructs. >> The question is whether the annotate file is sufficient to parse all >> 'user' source or does the original release file also have to be parsed >> to get some needed symbols and/or macros. >> > > No work, applying splint annotations takes practice, I'm rusty, > use it or lose it. I don't mind a bit ... > OK, I found my sqlite3 annotations buried in CVS: cvs -d :ext:anonymous at rpm5.org:/v/rpm/cvs get sqlite cd sqlite cvs up -D 2005-06-01 will find (for reference only, keep reading) what I did way back when. Meanwhile I've done the following (because 5 year old annotations are mostly useless imho): 1) built/installed splint from sourceforge (on rhel6 beta if it matters) 2) imported sqlite-3.6.23.1 (the tree, not the recommended amalgamation) 3) reapplied the annotations to ONLY src/sqlite.h.in which is expanded to become sqlite3.h (and that's what you seem to want/need if attempting to include the sqlite3 API within splint). 4) "make lint" lather rinse repeat to consitency Note also the splint disablers in the top level .splintrc. I haven't bothered turing on stricter checks, merely to bring forward the annotations from 2005-06-01. I did have to add a few new disablers, none that seem to directly affect sqlite3.h API annotations, but YMMV. All is now checked in at the cvs URI above. Running sh autogen.h will create a Makefile with a "make lint" target that runs splint. Note that I skipped several files because of issues with glibc includes and splint parsing errors: # src/os_os2.c # src/os_unix.c \ # src/os_win.c # src/shell.c \ The annotations I've added appear self-consistent with make lint although there are still 44 warnings of changes to global structures that aren't in the sqlite3.h API. If my fetishistic ritual annotating style (like this) is useful, I can bring forward other API's (zlib.h, bzip2.h, popt.h, neon.h, ...) in a similar fashion on a "time permitting" basis. hth 73 de Jeff From n3npq at mac.com Sat Jul 10 17:34:48 2010 From: n3npq at mac.com (Jeff Johnson) Date: Sat, 10 Jul 2010 17:34:48 -0400 Subject: [splint-discuss] Couple of observations re carrying API annotations in splint In-Reply-To: <76B1E4ED-4E38-4213-8205-7AC724AC74A1@mac.com> References: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> <76B1E4ED-4E38-4213-8205-7AC724AC74A1@mac.com> Message-ID: <5CF3DAFC-C051-413F-929A-BF4FCC49D3B0@mac.com> Overall I think the idea of extending splint to additional non-pOSIX API's is perfectly sane and useful Static annotations have a usage case, for automated QA testing, for detecting mis-use of API's and more. But there are gonna be gotchas: 1) API's change in the "real world" Whatever you carry in splint MUST be maintained somehow. There's the additional pain of whatever works on, say rhel6 with sqlite-3.6.23.1 may not be useful "portably". C'est la vie (but you need to warn users up front). 2) Manually applying annotations is quite a chore Literally months if not years of my life has been spent staring at splint spewage. Like all lint-like approaches there's an _ENORMOUS_ amount of warnings that need to be studied if working carefully. Automated tools (like what ISPRAS is doing, also sensitive to ' splint annotations) are gonna be needed to succeed in populating a store of statically annotated API's imho. 3) the splint C parser has some issues still Finding which file had "parser errors" by bisecting the file inputs using splint, while much improved, still has a ways to go to Just Work. You other additions to splint (seen while annotating) are quite nice, get a new release out for splint, you have nothing to be embarrased about imho. (aside) ISPRAS == Institute of System Programming, Russian Academy of Sciences These are the people who are putting meat & muscle into LSB "standard" interface testing. The tools ISPRAS is developing are quite pleasant to use, with web displays and low barriers to entry. See this link http://linuxtesting.org/upstream-tracker/ for one extremely useful (imho) tool tracking ABI's through versions. I can attest to the quality of the tool because two interfaces that I am responsible for creating/maintaining RPM & POPT are there. The tool does indeed find problem areas accurately. Another tool is their "shallow testing" scripts (which are quite easy to extend with pre- and post- code snippet templates in XML called abi-compliance-checker.pl api-sanity-autotest.pl which you can find a copy of in scripts/ from a top level check-out from cvs -d :ext:anonymous at rpm5.org:/v/rpm/cvs get rpm in the scripts/ sub-directory (I'm too lazy to find the link through linuxfoundation atm -- I posted here on the splint mailing list a couple months back). With a little work at automation, and perhaps asking LSB or ISPRAS to start generating splint files that Just Drop In automagically, I think you have a very very sound approach to using splint on OSS software. hth 73 de Jeff From splint at sympatico.ca Mon Jul 12 15:27:48 2010 From: splint at sympatico.ca (Bill Pringlemeir) Date: Mon, 12 Jul 2010 15:27:48 -0400 Subject: [splint-discuss] Couple of observations re carrying API annotations in splint In-Reply-To: <5CF3DAFC-C051-413F-929A-BF4FCC49D3B0@mac.com> (Jeff Johnson's message of "Sat, 10 Jul 2010 17:34:48 -0400") References: <5238AED0-8385-40CD-AE29-E75B67EEE273@mac.com> <7742B304-2398-4D13-8288-A5FD2FF3B263@mac.com> <76B1E4ED-4E38-4213-8205-7AC724AC74A1@mac.com> <5CF3DAFC-C051-413F-929A-BF4FCC49D3B0@mac.com> Message-ID: On 10 Jul 2010, n3npq at mac.com wrote: > Overall I think the idea of extending splint to additional > non-pOSIX API's is perfectly sane and useful Static annotations > have a usage case, for automated QA testing, for detecting > mis-use of API's and more. > But there are gonna be gotchas: push > 1) API's change in the "real world" push > 2) Manually applying annotations is quite a chore push > 3) the splint C parser has some issues still Finding which file had "parser pop 3) Yes. I hoped to extend the amount of code it can parse. I doubt it is every perfect in the presence of complex code constructs. Ie, deeply nested blocks, large code macros, etc. My hope was to fix some loose ends that people had noted and then maybe try to look more seriously about a gcc plugin that would support splint annotations... If someone hasn't already started in the mean time. pop 2) Yes. After annotation, however, it is quite easy to use. It is also generally faster as only the module under analysis has to be considered. Also, some of these annotations can actually be useful to code generators. Many splint annotations are similar to gcc attributes. Finally, I think that the annotations can be useful to a user to understand what the API is for. Currently splint lacks in verifying the correctness of some annotations. For instance, /*@falsewhennull@*/ bool isEmpty(/*@null@*/ char *p); verifies the caller but not the implementation. There are many reports of splint with SEGV. This is because an annotation like above is not consistent with the implementation (due to keep-going functionality added after the fact). Whole program (global checking) could be the future. However, it will only ever verify the current code base and not an ideal API. Only an annotation based solution can do that. Both need source code available. [insert proper tool for the job euphemism here]. I would guess that the static analysis tools of the future will do both. pop 1) I think that there are several parties interested in library API static analysis. This is really to speak to your first point. A library author would like to document the API and verify that the API is consistent with documentation and internal changes. A library user (a package) would like to know that the package works with various forms of the library. Finally, an end user (distribution vendors, security audits, etc) would like to verify that the entire base is consistent. I think this is what ISPRAS is doing. Mostly the concerns of the parties are similar. Having an splint annotated API is sort of like the formal LSB testing that ISPRAS is doing. If different versions of the library and dependant packages analyze cleanly with changes, they you have a good chance that no bugs have been introduced. This may be an internal change in the library, a change in the package, or both. If the API has changed, then a conditional (like STRICT in the splint system annotations) can be used to create splint specifications that are for multiple API versions. In many cases, API changes just add functionality so some prototypes, structures and enum values might be conditionalized in/out. This gives a package developer the chance for static analysis versus both API versions. Something an end user might not care about. > ISPRAS == Institute of System Programming, Russian Academy of Sciences > These are the people who are putting meat & muscle into LSB "standard" > interface testing. [snip] > With a little work at automation, and perhaps asking LSB or ISPRAS > to start generating splint files that Just Drop In automagically, > I think you have a very very sound approach to using splint > on OSS software. The dynamic testing tools are nice. I think that they have quite a bit in the way of dynamic security testing. I don't think they have data sanitization (SQL injection, relative path exploits, etc) automated in these tests. This is something that static analysis might do better with. Both static and dynamic tools are nice. Static tools will never test the compiler component. I think this is very important for C++ shared libraries. I hope something better comes along in the future. Splint works well for some means and not for others. Regards, Bill Pringlemeir. -- I never did give anybody hell. I just told the truth and they thought it was hell. - Harry S. Truman From susanin at ispras.ru Fri Jul 16 10:25:52 2010 From: susanin at ispras.ru (Andrey Ponomarenko) Date: Fri, 16 Jul 2010 18:25:52 +0400 Subject: [splint-discuss] Couple of observations re carrying API annotations in splint Message-ID: <4C406BF0.3090705@ispras.ru> Hello, I'm a developer of the tool named "api-sanity-autotest" that uses the splint annotations from the library header files. The tool itself is an automatic generator of basic runtime unit tests for C/C++ libraries. The tool uses the following annotations with the aim of improving the tests quality: @returned@, @out@, @notnull@, @requires@, @ensures@, @abstract at . And I have some suggestions for the splint evolution: 1) Add an ability to dump all annotations from the header file to the XML file. The option --dump-annotations will be very helpful for me. The format of dump may be the following: name of the interface annotated retval param1 param2 ... ensures ... ... 2) Add a @private@ annotation to the interface. It will tell the splint that this interface should not be verified. 3) Annotating the C++ code. Thanks! -- Andrey Ponomarenko Linux Verification Center, ISPRAS web: http://www.linuxtesting.org mail: upstream-tracker at linuxtesting.org