From codefritz at googlemail.com Wed Jul 2 08:52:40 2008 From: codefritz at googlemail.com (Fritz Code) Date: Wed, 2 Jul 2008 17:52:40 +0200 Subject: [splint-discuss] splint doesn't warn missing return evaluation Message-ID: <3e9cdced0807020852vd187630m58fb7dd5bfcfbf9b@mail.gmail.com> Hi all, for some functions I get an error that I don't evaluate the return value of a function. But on some other functions I don't! Although the function has an int return type. Using 3.1.2, my settings: +posixlib +bool-compare -castfcnptr +nullderef +weak Another question: +nullderef means that splint checks that there is no scenario where a null pointer gets dereferenced, and if it will print a warning,right? Despite that whats the difference to /*@ null @*/ annotation? Only that +nullderef is a global option and the annotation just local? thanks, -- Regards, --Codefritz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080702/e504e780/attachment.html From jagannath.sahoo at gmail.com Mon Jul 14 21:30:58 2008 From: jagannath.sahoo at gmail.com (jagannath.sahoo at gmail.com) Date: Tue, 15 Jul 2008 10:00:58 +0530 (IST) Subject: [splint-discuss] Spice up your mobile Message-ID: <378864390.1216096258802.JavaMail.SYSTEM@137128-db1> An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080715/3edbe034/attachment.html From JHolland at FASTSOFT.COM Fri Jul 18 13:19:13 2008 From: JHolland at FASTSOFT.COM (Jake Holland) Date: Fri, 18 Jul 2008 13:19:13 -0700 Subject: [splint-discuss] splint and c99 Message-ID: Hi. I joined this mailing list a few weeks ago because I would like to submit a patch. I sent mostly the same email then, but with the full (edited) cgrammar.y attached instead of a patch, and I got a warning about how it went to the moderator for being too big. I never got anything after that, so I thought I'd re-send something smaller. My apologies if you end up getting both messages. I've attached a patch for a problem I was having with splint. Would anybody here be interested in reviewing and commenting? And does anyone have advice on how I should go about getting this behavior into the official splint code base? A description of my problem and solution follows. One of the differences between C89 and C99 is illustrated with this function definition: int f() { int x = 0; x++; int y = 0; /* 0 */ y++; return x+y; } I believe the line marked "/* 0 */" is illegal in C89, but legal in C99. If I'm not mistaken, in C89, all variables declared inside a compound statement must be declared at the top of the compound statement. Once you have a statement which is not a declaration or its initializer, you can no longer declare more variables. In C99, I think the grammar for compound statements in section 6.8.2 indicates this is no longer a restriction. Splint version 3.1.2 (and, I believe, the latest dev version from cvs) report "Parse Error" for this code, giving the line number of the marked line. Our code base uses this feature of C99 in a number of places, and splint's handling of this case was a barrier to adopting splint in our build process. So I downloaded the splint source and took a look at cgrammar.y, and found a more or less reasonable way to allow it, I think without introducing any other significant changes. However, it's hard to be sure, given my utter unfamiliarity with the code base. This introduced 2 more shift/reduce conflicts (for a total now of 159, instead of the expected 157), but otherwise completed the make (including tests) without errors or warnings. (I did my build on cygwin under Windows Vista Home and Windows XP.) With this change, running splint on a file with the above function produced no errors. The key differences are between lines 1871 and 1888. I basically introduced some rules so that in a compound statement, either stmtLists could follow initializerLists, or vice versa. My first attempt had what I thought was a cleaner solution, with a rule allowing a stmt | initializer | stmt compoundRecurse | initializer compoundRecurse. However, this introduced extra reduce/reduce errors and some errors about parsing macros, so I tried this change, which seems not to conflict as heavily with other extensions. If somebody would prefer to help me pursue that approach to letting the change in the way it is, I think I can reproduce those details. Thanks in advance for any responses, Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080718/52cc25f6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: cgrammar.y.patch Type: application/octet-stream Size: 2294 bytes Desc: cgrammar.y.patch Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080718/52cc25f6/attachment.obj From Michael.Wojcik at microfocus.com Fri Jul 18 15:01:19 2008 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 18 Jul 2008 15:01:19 -0700 Subject: [splint-discuss] splint and c99 In-Reply-To: References: Message-ID: <11352F9641010A418AD5057945A3A6590118B75E@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of Jake Holland > Sent: Friday, 18 July, 2008 14:19 A word of advice: you may get more response if you send plain-text email. I suspect I'm not the only one here who is not a fan of HTML email. > I believe the line marked "/* 0 */" is illegal in C89, but legal in C99. > If I'm not mistaken, in C89, all variables declared inside a compound > statement must be declared at the top of the compound statement. Correct. > In C99, I think the grammar for compound statements in section 6.8.2 > indicates this is no longer a restriction. Correct. > Splint version 3.1.2 (and, I believe, the latest dev version from cvs) > report "Parse Error" for this code, giving the line number of the marked > line. Correct. Splint is a C89 implementation. I'm afraid I can't offer much advice for your larger question (whether your patch, or some variation on it, should be accepted into the Splint sources). I'm not even entirely sure Splint currently has a maintainer - though I have a note from July 2007 indicating that Andy Lester had agreed to take on that role. One difficulty is C99 introduced quite a few changes, and it might be incongruous, if not downright confusing, to only support one. Another is that if people expect Splint to be a conforming C89 implementation, and it silently accepts a C99ism, that could reasonably be considered a false negative. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From john.carter at tait.co.nz Wed Jul 30 16:24:43 2008 From: john.carter at tait.co.nz (John Carter) Date: Thu, 31 Jul 2008 11:24:43 +1200 (NZST) Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap Message-ID: Here are some bugs I have found in Splint-3.1.2... 1) Meta bug :-) There doesn't seem to be a 3.1.2 tag in the CVS repository! 2) Splint 3.1.2 chokes on unary + eg... int i = +1; 3) I started hunting a sporadic bug when I decided it would be easier to use gcc-4.2.3's "mudflap" facility.... So I pulled out the CVS latest version of splint and compiled it with mudflap checking when I hit a Bug Bonanza... In src/lcllib.c:432 an array of length 128 is used as a buffer for input from read_readline.... # define BUFLEN 128 static bool loadLCDFile (FILE *f, cstring name) { char buf[BUFLEN]; /* ** Check version. Should be >= SPLINT_LIBVERSION */ if (reader_readLine (f, buf, BUFLEN) == NULL In src/reader.c:234 char *reader_readLine (FILE *f, char *s, int max) { char *res = fgets (s, MAX_DUMP_LINE_LENGTH, f); Where in src/Headers/constants.h # define MAX_DUMP_LINE_LENGTH 16384 ie. Sometimes dynamic checking tools beats static analysis. :-)) An example of the mudflap output from the build time tests are appended below. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter at tait.co.nz New Zealand ../src/splint -supcounts -nof -incondefs -nolib +impconj -DSTRICT standard.h posix.h unix.h stdio.h stdlib.h -dump unixstrict Splint 3.1.2 --- 31 Jul 2008 Finished checking --- no warnings make[2]: Leaving directory `/home/johnc/builds/splint/lib' Making all in imports make[2]: Entering directory `/home/johnc/builds/splint/imports' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/johnc/builds/splint/imports' Making all in test make[2]: Entering directory `/home/johnc/builds/splint/test' Testing splint 3.1.2... Version Info: Splint 3.1.2 --- 31 Jul 2008 Maintainer: splint-bug at splint.org Compiled using /opt/gcc-4.2.3/bin/gcc -g3 -O0 -fmudflap on Linux parore 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux by johnc Splint 3.1.2 --- 31 Jul 2008 LARCH_PATH = (default = .:/usr/local/share/splint/lib:/home/johnc/buil ds/splint/lib:) --- path used to find larch initialization files and LSL traits LCLIMPORTDIR = --- directory containing lcl standard library files (import with < ... >) include path = (set by environment variable CPATH and -I flags) --- path used to find #include'd files systemdirs = /usr/ (set by -systemdirs or environment variable CPATH) --- if file is found on this path, it is treated as a system file for error reporting Tests: Checking help... 50a51,142 > ******* > mudflap violation 1 (check/write): time=1217457834.392845 ptr=0xbffbec9c size=16384 > pc=0x40026e65 location=`(fgets buffer)' > /opt/gcc-4.2.3/lib/libmudflap.so.0(__mf_backtrace+0x4d) [0x40024981] > Nearby object 1: checked region begins 0B into and ends 16256B after > mudflap object 0x882fdc8: name=`lcllib.c:432 (loadLCDFile) buf' > bounds=[0xbffbec9c,0xbffbed1b] size=128 area=stack check=0r/3w liveness=3 > alloc time=1217457834.392755 pc=0x400268f7 > Nearby object 2: checked region begins 216B before and ends 16164B after > mudflap object 0x882aa90: name=`lcllib.c:335 (loadStandardState) fpath' > bounds=[0xbffbed74,0xbffbed77] size=4 area=stack check=0r/4w liveness=4 > alloc time=1217457834.391718 pc=0x400268f7 > Nearby object 3: checked region begins 580B before and ends 15800B after > mudflap object 0x881c568: name=`llmain.c:384 (main) passThroughArgs' > bounds=[0xbffbeee0,0xbffbeee3] size=4 area=stack check=0r/3w liveness=3 > alloc time=1217457834.386240 pc=0x400268f7 > Nearby object 66: checked region begins 104B before and ends 16276B after > mudflap dead object 0x882edc8: name=`message.c:156 (message) pvar' > bounds=[0xbffbed04,0xbffbed07] size=4 area=stack check=0r/0w liveness=0 > alloc time=1217457834.392253 pc=0x400268f7 > dealloc time=1217457834.392750 pc=0x400268a8 > number of nearby objects: 66 > ******* > mudflap violation 3 (check/write): time=1217457834.393553 ptr=0xbffbec9c size=16384 > pc=0x40026e65 location=`(fgets buffer)' > /opt/gcc-4.2.3/lib/libmudflap.so.0(__mf_backtrace+0x4d) [0x40024981] > Nearby object 1: checked region begins 0B into and ends 16256B after > mudflap object 0x882fdc8: name=`lcllib.c:432 (loadLCDFile) buf' > Nearby object 2: checked region begins 216B before and ends 16164B after > mudflap object 0x882aa90: name=`lcllib.c:335 (loadStandardState) fpath' > Nearby object 3: checked region begins 580B before and ends 15800B after > mudflap object 0x881c568: name=`llmain.c:384 (main) passThroughArgs' > Nearby object 66: checked region begins 104B before and ends 16276B after > mudflap dead object 0x882edc8: name=`message.c:156 (message) pvar' > number of nearby objects: 66 Compilation finished at Thu Jul 31 10:54:10 From john.carter at tait.co.nz Wed Jul 30 18:46:49 2008 From: john.carter at tait.co.nz (John Carter) Date: Thu, 31 Jul 2008 13:46:49 +1200 (NZST) Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: References: Message-ID: For something dedicated to static analysis... I find it curious that splint is anything but "-Wall -W" warnings clean! Particularly alarming to me are the "Function uses uninitialized variable..." warnings. This first patch fixes two of those, but there are many more. The second patch fixes the bug uncovered by mudflap I mentioned in my previous mail. The third patch fixes a preprocessor warning in osd.c Thanks! Index: src/cppexp.c =================================================================== RCS file: /cvsroot/splint/splint/src/cppexp.c,v retrieving revision 1.24 diff -u -r1.24 cppexp.c --- src/cppexp.c 18 May 2004 19:07:46 -0000 1.24 +++ src/cppexp.c 31 Jul 2008 01:40:55 -0000 @@ -240,7 +240,7 @@ struct operation cppReader_parseNumber (cppReader *pfile, char *start, int olen) /*@requires maxRead(start) >= (olen - 1) @*/ { - struct operation op; + struct operation op = {0,0,0,0,0}; char *p = start; char c; int i; @@ -417,7 +417,7 @@ char c; register struct token *toktab; enum cpp_token token; - struct operation op; + struct operation op = {0,0,0,0,0}; char *tok_start, *tok_end; int old_written; Index: src/lcllib.c =================================================================== RCS file: /cvsroot/splint/splint/src/lcllib.c,v retrieving revision 1.31 diff -u -r1.31 lcllib.c --- src/lcllib.c 18 May 2004 19:07:47 -0000 1.31 +++ src/lcllib.c 31 Jul 2008 01:40:55 -0000 @@ -424,7 +424,7 @@ } /*@constant int BUFLEN;@*/ -# define BUFLEN 128 +# define BUFLEN MAX_DUMP_LINE_LENGTH static bool loadLCDFile (FILE *f, cstring name) Index: src/osd.c =================================================================== RCS file: /cvsroot/splint/splint/src/osd.c,v retrieving revision 1.43 diff -u -r1.43 osd.c --- src/osd.c 10 Aug 2007 22:31:05 -0000 1.43 +++ src/osd.c 31 Jul 2008 01:40:55 -0000 @@ -862,7 +862,7 @@ # if defined (UNIX) char *buf = dmalloc (sizeof (*buf) * MAXPATHLEN); char *cwd = getcwd (buf, MAXPATHLEN); -#else if defined (OS2) +#elif defined (OS2) char *buf = dmalloc (sizeof (*buf) * MAXPATHLEN); char *cwd = _getcwd2 (buf, MAXPATHLEN); char *slash; John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter at tait.co.nz New Zealand From john.carter at tait.co.nz Wed Jul 30 19:30:55 2008 From: john.carter at tait.co.nz (John Carter) Date: Thu, 31 Jul 2008 14:30:55 +1200 (NZST) Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: References: Message-ID: While this is a fix for the immediate problem, it is not a good fix. > Index: src/lcllib.c > =================================================================== > RCS file: /cvsroot/splint/splint/src/lcllib.c,v > retrieving revision 1.31 > diff -u -r1.31 lcllib.c > --- src/lcllib.c 18 May 2004 19:07:47 -0000 1.31 > +++ src/lcllib.c 31 Jul 2008 01:40:55 -0000 > @@ -424,7 +424,7 @@ > } > > /*@constant int BUFLEN;@*/ > -# define BUFLEN 128 > +# define BUFLEN MAX_DUMP_LINE_LENGTH > > static bool > loadLCDFile (FILE *f, cstring name) The basic problem is this function ignores it "max" parameter. char *reader_readLine (FILE *f, char *s, int max) { char *res = fgets (s, MAX_DUMP_LINE_LENGTH, f); if (res != NULL) { if (strlen (res) == size_fromInt (MAX_DUMP_LINE_LENGTH - 1)) { llfatalerrorLoc (message ("Maximum line length exceeded (%d): %s", max, cstring_fromChars (s))); } incLine (); } return res; } John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter at tait.co.nz New Zealand From ok at cs.otago.ac.nz Wed Jul 30 19:27:11 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 31 Jul 2008 14:27:11 +1200 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: References: Message-ID: On 31 Jul 2008, at 1:46 pm, John Carter wrote: > For something dedicated to static analysis... I find it curious that > splint is anything but "-Wall -W" warnings clean! It is only intended to be splint-clean. > > > Particularly alarming to me are the "Function uses uninitialized > variable..." warnings. Gcc very often cries wolf; have you checked to ensure whether these are real problems, or whether they are simply a defect in Gcc? I suspect the latter. { > - struct operation op; > + struct operation op = {0,0,0,0,0}; This adds extra runtime overhead, but clearly does not fix any real bug, unlike the other kinds of changes provided. From Michael.Wojcik at MicroFocus.com Thu Jul 31 06:41:36 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Thu, 31 Jul 2008 06:41:36 -0700 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: References: Message-ID: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Richard A. O'Keefe > Sent: Wednesday, 30 July, 2008 22:27 > > On 31 Jul 2008, at 1:46 pm, John Carter wrote: > > > - struct operation op; > > + struct operation op = {0,0,0,0,0}; > > This adds extra runtime overhead, but clearly does not fix > any real bug, unlike the other kinds of changes provided. It's also unnecessarily verbose, since: struct operation op = {0}; will initialize all members of op appropriately (integer types to 0, floating types to 0.0, pointers to null, and recursively for aggregate types), regardless of the number of members. The runtime overhead is negligible, and personally I'd just as soon see automatic variables initialized; but some people prefer to avoid initializing automatics that should be assigned only at runtime, so analyzers can catch accidental use before assignment. -- Michael Wojcik Principal Software Systems Developer, Micro Focus