From jeremy at cowgar.com Wed Oct 11 07:18:15 2006 From: jeremy at cowgar.com (Jeremy Cowgar) Date: Wed Oct 11 07:19:26 2006 Subject: [splint-discuss] Warnings when using g_assert Message-ID: When I use g_assert: g_assert (g_file_test ("config.ini", G_FILE_TEST_EXISTS) == 0); I get 3 warnings: main.c:16:6: Test expression for if not boolean, type int: 1 Test expression type is not boolean or int. (Use -predboolint to inhibit warning) main.c:16:103: Null storage passed as non-null param: g_log (((gchar *)0), ...) A possibly null pointer is passed as a parameter corresponding to a formal parameter with no /*@null@*/ annotation. If NULL may be used for this parameter, add a /*@null@*/ annotation to the function parameter declaration. (Use -nullpass to inhibit warning) main.c:16:345: Statement has no effect: (void)0 Statement has no visible effect --- no values are modified. (Use - noeffect to inhibit warning) All three of these warnings are warnings I cannot do anything about w/ o altering glib code, which I obviously do not want. I can disable these checks via command line switches, but I don't want to because I want to be able to detect these problems in my own code. Is there another way of causing these warnings not to appear? I tried all sorts of things about not expanding macros with prefix g_, etc... but I couldn't get these messages to go away. I am running splint like: splint $(INCLUDES) -sys-dirs /usr/include:/sw/include *.c glib.h and it's variants are located under /sw/include. Thanks. Jeremy From lholzheid at bihl-wiedemann.de Wed Oct 11 09:42:39 2006 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Wed Oct 11 09:42:53 2006 Subject: [splint-discuss] Warnings when using g_assert In-Reply-To: References: Message-ID: <20061011134239.GA18111@svr5.bihl-wiedemann.de> On Wed, 2006-10-11 07:18:15 -0400, Jeremy Cowgar wrote: > [..] > I can disable these checks via command line switches, but I don't > want to because I want to be able to detect these problems in my own > code. Is there another way of causing these warnings not to appear? Jeremy, it should be possible to locally disable these warnings by annotating the sources, e.g. by writing /*@-predboolint@*/ /*@-nullpass@*/ /*@-noeffect@*/ above the g_assert() line and /*@=predboolint@*/ /*@=nullpass@*/ /*@=noeffect@*/ below. Another possibility is to tell splint you expect a certain number of warnings for certain a line: /*@i3@*/ g_assert( ... or to disable warnings for a certain line altogether: /*@i@*/ g_assert( ... I'd prefer '/*@i3@*/'. hope this helps, Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From jeremy at cowgar.com Wed Oct 11 09:45:52 2006 From: jeremy at cowgar.com (Jeremy Cowgar) Date: Wed Oct 11 09:47:11 2006 Subject: [splint-discuss] Warnings when using g_assert In-Reply-To: <20061011134239.GA18111@svr5.bihl-wiedemann.de> References: <20061011134239.GA18111@svr5.bihl-wiedemann.de> Message-ID: <4C94F260-A2A6-4BE9-8B87-57491F63DE60@cowgar.com> That will get rid of the error, but I use g_assert 100's of times. Jeremy On Oct 11, 2006, at 9:42 AM, Ludolf Holzheid wrote: > On Wed, 2006-10-11 07:18:15 -0400, Jeremy Cowgar wrote: >> [..] >> I can disable these checks via command line switches, but I don't >> want to because I want to be able to detect these problems in my own >> code. Is there another way of causing these warnings not to appear? > > Jeremy, > > it should be possible to locally disable these warnings by annotating > the sources, e.g. by writing > > /*@-predboolint@*/ /*@-nullpass@*/ /*@-noeffect@*/ > > above the g_assert() line and > > /*@=predboolint@*/ /*@=nullpass@*/ /*@=noeffect@*/ > > below. > > Another possibility is to tell splint you expect a certain number of > warnings for certain a line: > > /*@i3@*/ g_assert( ... > > or to disable warnings for a certain line altogether: > > /*@i@*/ g_assert( ... > > > I'd prefer '/*@i3@*/'. > > hope this helps, > > Ludolf > > -- > > --------------------------------------------------------------- > Ludolf Holzheid Tel: +49 621 339960 > Bihl+Wiedemann GmbH Fax: +49 621 3392239 > Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de > D-68199 Mannheim, Germany > --------------------------------------------------------------- > From Michael.Wojcik at MicroFocus.com Wed Oct 11 09:59:25 2006 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed Oct 11 10:03:10 2006 Subject: [splint-discuss] Warnings when using g_assert In-Reply-To: Message-ID: <11352F9641010A418AD5057945A3A6598B3A97@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Jeremy Cowgar > Sent: Wednesday, 11 October, 2006 07:18 > > When I use g_assert: > > g_assert (g_file_test ("config.ini", G_FILE_TEST_EXISTS) == 0); > > I get 3 warnings: > > main.c:16:6: Test expression for if not boolean, type int: 1 > Test expression type is not boolean or int. (Use -predboolint to > inhibit > warning) > main.c:16:103: Null storage passed as non-null param: g_log (((gchar > *)0), ...) > A possibly null pointer is passed as a parameter corresponding to > a formal > parameter with no /*@null@*/ annotation. If NULL may be used for > this > parameter, add a /*@null@*/ annotation to the function parameter > declaration. > (Use -nullpass to inhibit warning) > main.c:16:345: Statement has no effect: (void)0 > Statement has no visible effect --- no values are modified. (Use - > noeffect to > inhibit warning) > > All three of these warnings are warnings I cannot do anything about w/ > o altering glib code, which I obviously do not want. I can disable > these checks via command line switches, but I don't want to because I > want to be able to detect these problems in my own code. Is there > another way of causing these warnings not to appear? You could put: /*@-predboolint -nullpass -noeffect@*/ before each use of g_assert, and: /*@=predboolint =nullpass =noeffect@*/ after each of them. If that's onerous, use the standard assert macro, or define your own. You don't say why you're using g_assert rather than assert, so we can't tell if it's providing some critical functionality for you. (I have no experience with g_assert myself; I don't believe assertions are an appropriate error-handling mechanism, so I don't use them. The GLib reference I just checked gives no indication that g_assert does anything special.) -- Michael Wojcik Principal Software Systems Developer Micro Focus michael.wojcik@microfocus.com 9420 Key West Avenue Rockville, MD 20850 Direct: 517 676 0892 What would you like Micro Focus to do for you? Contribute your view by visiting http://www.microfocus.com/CustomerInsight.asp From spam_account at sympatico.ca Wed Oct 11 10:32:40 2006 From: spam_account at sympatico.ca (spam_account@sympatico.ca) Date: Wed Oct 11 10:34:45 2006 Subject: [splint-discuss] Warnings when using g_assert In-Reply-To: References: Message-ID: On 11 Oct 2006, jeremy@cowgar.com wrote: > When I use g_assert: > g_assert (g_file_test ("config.ini", G_FILE_TEST_EXISTS) == 0); > I get 3 warnings: [snip] > All three of these warnings are warnings I cannot do anything about > w/ o altering glib code, which I obviously do not want. I can ... Well, actually the best solution might be to modify the glib headers. This is the solutions used for library headers. Glib headers with annotations would be most useful for debugging this code. Sorry, I don't have such files and I don't know where they would exist. Perhaps a contrib to splint, glib (or some separate project) would help. A major problem is the amount of revisions of the glib libraries. I guess that the minor versions of Glib should have the same API, so only one version (conditional) would be needed for the major revisions. Hiding implementation details from splinted code would also be a plus... I had started to do this with a Glib/GTK project. However, I found that the GCC vararg macros were problematic. I tried to redefine the macros as a function. Eventually I got to the point where splint wanted the function definitions, I believe it was failing due to parsing errors. I am interested in this and GTK as well. Does anyone have pointers to previous work done on this? Any pointers on doing this with other APIs? If files are submitted to the list, would the get incorporated into the CVS code at source forge? Fwiw, Bill Pringlemeir. From spam_account at sympatico.ca Wed Oct 11 10:32:40 2006 From: spam_account at sympatico.ca (spam_account@sympatico.ca) Date: Wed Oct 11 10:34:47 2006 Subject: [splint-discuss] Warnings when using g_assert In-Reply-To: References: Message-ID: On 11 Oct 2006, jeremy@cowgar.com wrote: > When I use g_assert: > g_assert (g_file_test ("config.ini", G_FILE_TEST_EXISTS) == 0); > I get 3 warnings: [snip] > All three of these warnings are warnings I cannot do anything about > w/ o altering glib code, which I obviously do not want. I can ... Well, actually the best solution might be to modify the glib headers. This is the solutions used for library headers. Glib headers with annotations would be most useful for debugging this code. Sorry, I don't have such files and I don't know where they would exist. Perhaps a contrib to splint, glib (or some separate project) would help. A major problem is the amount of revisions of the glib libraries. I guess that the minor versions of Glib should have the same API, so only one version (conditional) would be needed for the major revisions. Hiding implementation details from splinted code would also be a plus... I had started to do this with a Glib/GTK project. However, I found that the GCC vararg macros were problematic. I tried to redefine the macros as a function. Eventually I got to the point where splint wanted the function definitions, I believe it was failing due to parsing errors. I am interested in this and GTK as well. Does anyone have pointers to previous work done on this? Any pointers on doing this with other APIs? If files are submitted to the list, would the get incorporated into the CVS code at source forge? Fwiw, Bill Pringlemeir. From lholzheid at bihl-wiedemann.de Wed Oct 11 12:47:38 2006 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Wed Oct 11 12:47:46 2006 Subject: [splint-discuss] Warnings when using g_assert In-Reply-To: <4C94F260-A2A6-4BE9-8B87-57491F63DE60@cowgar.com> References: <20061011134239.GA18111@svr5.bihl-wiedemann.de> <4C94F260-A2A6-4BE9-8B87-57491F63DE60@cowgar.com> Message-ID: <20061011164738.GA16809@svr5.bihl-wiedemann.de> On Wed, 2006-10-11 09:45:52 -0400, Jeremy Cowgar wrote: > That will get rid of the error, but I use g_assert 100's of times. If you don't want to change your sources, you might run splint on sources piped through sed: %.o : %.c gcc $< sed -e 's:g_assert:/\*@i@\*/ g_assert:' $< > tmp.c splint tmp.c | sed -e "s/tmp\.c/$ Ich werde ab 10.10.2006 nicht im B?ro sein. Ich kehre zur?ck am 22.10.2006. I am out of office 11..22-Oct-06. After my return I will take care of your mail.In urgent cases please contact Helmut Elmer, Olaf Brust or Sabine Gorkotte From mrv at corecom.co.kr Wed Oct 25 02:36:09 2006 From: mrv at corecom.co.kr (Roman Mashak) Date: Wed Oct 25 02:36:16 2006 Subject: [splint-discuss] 'splint' and sys/types.h Message-ID: <000401c6f7ff$dbadcf00$9d0ba8c0@mrv> Hello, I'm new to 'splint' and ran into tricky case. Snippet of simple code I'm running on RedHat 8.0 (glibc-2.2.93) is the following: #include #include #include #include #define BUFSIZE 1500 int main(void) { ... return 0; } And splint chokes on the line including netinet/ip.h: %splint +posixlib foo.c Splint 3.1.1 --- 08 Mar 2004 usr/include/netinet/ip.h:31:13: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. The line 'splint' stuck on is: u_int8_t len; I followed documentation suggestions and enclosed the code with the lines: /*@-skipposixheaders@*/ #include /*@=skipposixheaders@*/ #include but it didn't help. What's the reason of such behavior and how to proceed? Thanks in advance. With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From Michael.Wojcik at MicroFocus.com Wed Oct 25 10:38:04 2006 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed Oct 25 10:49:36 2006 Subject: [splint-discuss] 'splint' and sys/types.h In-Reply-To: <000401c6f7ff$dbadcf00$9d0ba8c0@mrv> Message-ID: <11352F9641010A418AD5057945A3A6598B3B40@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Roman Mashak > Sent: Wednesday, 25 October, 2006 02:36 > > Snippet of simple code I'm running on RedHat 8.0 > (glibc-2.2.93) is the following: > > #include > #include > #include > #include > > #define BUFSIZE 1500 > > int main(void) > { > ... > > return 0; > } > > And splint chokes on the line including netinet/ip.h: > > %splint +posixlib foo.c > Splint 3.1.1 --- 08 Mar 2004 > > usr/include/netinet/ip.h:31:13: Parse Error. (For help on parse errors, see > splint -help parseerrors.) > *** Cannot continue. > > The line 'splint' stuck on is: > > u_int8_t len; So Splint hasn't seen a definition of u_int8_t. Without seeing your development environment, I can't tell where that's supposed to be defined, but presumably it's in one of the headers that Splint is skipping because it's a "standard" header that Splint has predefined. (The standard headers here include both those defined by ISO C90 and whatever version of POSIX Splint was last updated for - 1995, maybe.) > I followed documentation suggestions and enclosed the code with the lines: > > /*@-skipposixheaders@*/ > #include > /*@=skipposixheaders@*/ > #include > > but it didn't help. This told Splint to stop treating POSIX headers specially (ie, to parse them as it does for normal headers) before including sys/types.h, and then to revert to its previous setting after including it. (The previous setting is to skip POSIX headers and use Splint's predefined POSIX definitions, since you invoked Splint with +posixlib.) If you're still getting the error, then u_int8_t was not defined by that inclusion of sys/types.h. There are various possibilities: - u_int8_t is not defined by sys/types.h, but by some other POSIX or ISO header included by netinet/ip.h. - sys/types.h was already included earlier in the program, possibly included by stdio.h or stdlib.h, so the explicit inclusion in your program is a no-op anyway. - u_int8_t is only defined (by sys/types.h or whatever) if some token is defined, and your Splint configuration doesn't define it. Make sure that your Splint configuration includes all the predefined identifiers that are set by your compiler. (See the gcc docs - there's some option that dumps a list of the predefs, I believe.) - There's a bug in Splint's handling of POSIX headers. - Something else that I haven't thought of at the moment. I'd start by checking for missing predefines in the Splint configuration. If that doesn't reveal the problem, try pre-processing the source with gcc (what's that - the -P option, maybe?) and finding out just where u_int8_t actually gets defined for this program. Then you'll know where to put your skipposixheaders annotations. -- Michael Wojcik Principal Software Systems Developer Micro Focus michael.wojcik@microfocus.com 9420 Key West Avenue Rockville, MD 20850 What would you like Micro Focus to do for you? Contribute your view by visiting http://www.microfocus.com/CustomerInsight.asp From aabelka at gmail.com Wed Oct 25 08:39:46 2006 From: aabelka at gmail.com (ABDESSELEM Belkacem) Date: Wed Oct 25 14:34:44 2006 Subject: [splint-discuss] 'splint' and sys/types.h In-Reply-To: <000401c6f7ff$dbadcf00$9d0ba8c0@mrv> References: <000401c6f7ff$dbadcf00$9d0ba8c0@mrv> Message-ID: <8586aeb00610250539s3feec052v6d6e01041b4e4ae4@mail.gmail.com> I think that u_int8_t is defined in UNIX not in POSIX. Try with +unixlib. Belkacem On 10/25/06, Roman Mashak wrote: > > Hello, > > I'm new to 'splint' and ran into tricky case. > > Snippet of simple code I'm running on RedHat 8.0 (glibc-2.2.93) is the > following: > > #include > #include > #include > #include > > #define BUFSIZE 1500 > > int main(void) > { > ... > > return 0; > } > > And splint chokes on the line including netinet/ip.h: > > %splint +posixlib foo.c > Splint 3.1.1 --- 08 Mar 2004 > > usr/include/netinet/ip.h:31:13: Parse Error. (For help on parse errors, > see > splint -help parseerrors.) > *** Cannot continue. > > The line 'splint' stuck on is: > > u_int8_t len; > > I followed documentation suggestions and enclosed the code with the lines: > > /*@-skipposixheaders@*/ > #include > /*@=skipposixheaders@*/ > #include > > but it didn't help. What's the reason of such behavior and how to proceed? > > Thanks in advance. > > With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr > > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > -- B. Abdesselem -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20061025/ee9b672e/attachment.htm From ok at cs.otago.ac.nz Thu Oct 26 00:54:09 2006 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Oct 26 01:06:47 2006 Subject: [splint-discuss] 'splint' and sys/types.h Message-ID: <200610260454.k9Q4s9oI136629@atlas.otago.ac.nz> This particular issue has been discussed thoroughly in the mailing list before. From mrv at corecom.co.kr Thu Oct 26 01:26:30 2006 From: mrv at corecom.co.kr (Roman Mashak) Date: Thu Oct 26 02:04:21 2006 Subject: [splint-discuss] 'splint' and sys/types.h References: <11352F9641010A418AD5057945A3A6598B3B40@MTV-EXCHANGE.microfocus.com> Message-ID: <007e01c6f8bf$4b74b6e0$9d0ba8c0@mrv> Hello, Michael! You wrote to "Discussions about the Splint annotation-assisted static analysisproject" on Wed, 25 Oct 2006 07:38:04 -0700: [skip] MW> I'd start by checking for missing predefines in the Splint MW> configuration. If that doesn't reveal the problem, try pre-processing MW> the source with gcc (what's that - the -P option, maybe?) and finding MW> out just where u_int8_t actually gets defined for this program. Then MW> you'll know where to put your skipposixheaders annotations. I ran preprocessor (gcc -E) and found 'u_int8_t' has been really defined in sys/types.h: typedef unsigned int u_int8_t __attribute__ ((__mode__ (__QI__))); I put this line directly into the code, removed inclusion of sys/types.h and this made splint happy. The problem seems to be different. Also 'splint' processes the code fine, if the definition of the 'u_int8_t' (or another) is supplied in command line (but it's just a workaround): %splint -Du_int8_t="unsigned int" +posixlib.c foo.c With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From Michael.Wojcik at MicroFocus.com Thu Oct 26 09:28:23 2006 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Thu Oct 26 09:28:52 2006 Subject: [splint-discuss] 'splint' and sys/types.h In-Reply-To: <007e01c6f8bf$4b74b6e0$9d0ba8c0@mrv> Message-ID: <11352F9641010A418AD5057945A3A6598B3B4B@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Roman Mashak > Sent: Thursday, 26 October, 2006 01:27 > > MW> I'd start by checking for missing predefines in the Splint > MW> configuration. If that doesn't reveal the problem, try pre-processing > MW> the source with gcc ... and finding > MW> out just where u_int8_t actually gets defined for this program. Then > MW> you'll know where to put your skipposixheaders annotations. > > I ran preprocessor (gcc -E) and found 'u_int8_t' has been > really defined in sys/types.h: > > typedef unsigned int u_int8_t __attribute__ ((__mode__ (__QI__))); > > I put this line directly into the code, removed inclusion of sys/types.h and > this made splint happy. The problem seems to be different. No, I'm afraid that doesn't demonstrate anything of the sort. First, what you wrote above doesn't demonstrate that sys/types.h is actually defining u_int8_t *at the point where you explicitly include it in your program*. It may be, but as I wrote previously, sys/types.h may be included by some earlier header, rendering your Splint annotation moot. Second, there's no guarantee that the result of preprocessing with gcc will be the same as what the Splint parser sees. You still have to find out why you get that definition from sys/types.h when you preprocess with gcc, and not when you parse with Splint. Again, conditional compilation and a different set of predefined macros is the most likely explanation. (Richard O'Keefe wrote in another note that this issue has been discussed on the list before, so you might want to download the archives - follow the link at the bottom of every list message - and search through them. Unfortunately, that's hardly convenient.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus From mrv at corecom.co.kr Thu Oct 26 21:33:48 2006 From: mrv at corecom.co.kr (Roman Mashak) Date: Thu Oct 26 21:37:36 2006 Subject: [splint-discuss] 'splint' and sys/types.h References: <11352F9641010A418AD5057945A3A6598B3B4B@MTV-EXCHANGE.microfocus.com> Message-ID: <00d201c6f967$f4047b80$9d0ba8c0@mrv> Hello, Michael! You wrote to "Discussions about the Splint annotation-assisted static analysisproject" on Thu, 26 Oct 2006 06:28:23 -0700: MW> No, I'm afraid that doesn't demonstrate anything of the sort. First, MW> what you wrote above doesn't demonstrate that sys/types.h is actually MW> defining u_int8_t *at the point where you explicitly include it in your MW> program*. It may be, but as I wrote previously, sys/types.h may be MW> included by some earlier header, rendering your Splint annotation moot. No, the sample code I'm testing has only one header file - sys/types.h. It's interesting to note that if I include 'sys/types.h' and don't declare the variable of type 'u_int8_t' (or whatever from sys/types.h), then it's perfectly passed through splint. MW> Second, there's no guarantee that the result of preprocessing with gcc MW> will be the same as what the Splint parser sees. You still have to MW> find out why you get that definition from sys/types.h when you MW> preprocess with gcc, and not when you parse with Splint. Is there a way to see the output what 'splint' is parser? MW> Again, conditional compilation and a different set of predefined macros MW> is the most likely explanation. MW> (Richard O'Keefe wrote in another note that this issue has been MW> discussed on the list before, so you might want to download the MW> archives - follow the link at the bottom of every list message - and MW> search through them. Unfortunately, that's hardly convenient.) In archives I've found only one suggested solution so far: write my own splint-specific sys/types.h #ifdef S_SPLINT_S # include "splint-include/sys/types.h" #else # include #endif ==== splint-include/sys/types.h ==== typedef /*@unsignedintegraltype@*/ u_int8_t; /* ... other definitions ... */ ==== EOF ==== With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From brian.quinlan at iolfree.ie Fri Oct 27 05:45:13 2006 From: brian.quinlan at iolfree.ie (Brian Quinlan) Date: Fri Oct 27 05:47:34 2006 Subject: [splint-discuss] 'splint' and sys/types.h In-Reply-To: <00d201c6f967$f4047b80$9d0ba8c0@mrv> References: <11352F9641010A418AD5057945A3A6598B3B4B@MTV-EXCHANGE.microfocus.com> <00d201c6f967$f4047b80$9d0ba8c0@mrv> Message-ID: <1161942313.5131.66.camel@akebono> > MW> Second, there's no guarantee that the result of preprocessing with gcc > MW> will be the same as what the Splint parser sees. You still have to > MW> find out why you get that definition from sys/types.h when you > MW> preprocess with gcc, and not when you parse with Splint. > Is there a way to see the output what 'splint' is parser? > Hi Roman, Use +keep on the splint command-line to keep temporary files. If you're using gcc as your compiler, --save-temps has the same effect, so you can compare its preprocessor output with that of Splint. Bye, Brian