From dean.halter at notes.udayton.edu Fri Feb 10 10:27:10 2006 From: dean.halter at notes.udayton.edu (Dean Halter) Date: Wed Mar 22 17:11:24 2006 Subject: [splint-discuss] aclocal version error making splint Message-ID: <1139585230.7561.4.camel@logistics> Hi. I recently downloaded the splint tarball and configured it per the instructions for a Solaris installation. When i run 'gmake install', it gives me the following error: # gmake install cd . && /bin/bash /home/cpsadmin/splint-3.1.1/config/missing --run aclocal-1.6 /home/cpsadmin/splint-3.1.1/config/missing: line 46: aclocal-1.6: command not found WARNING: `aclocal-1.6' is needed, and you do not seem to have it handy on your system. You might have modified some files without having the proper tools for further handling them. Check the `README' file, it often tells you about the needed prerequirements for installing this package. You may also peek at any GNU archive site, in case some other package would contain this missing `aclocal-1.6' program. gmake: *** [aclocal.m4] Error 1 The aclocal version installed is 1.8.3. I see, from the Jan 2004 archives, this was discussed. Anyone ever come up with a formal solution? Thanks in advance. Dean Halter From Ralf.Wildenhues at gmx.de Fri Feb 10 10:44:50 2006 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:11:24 2006 Subject: [splint-discuss] aclocal version error making splint In-Reply-To: <1139585230.7561.4.camel@logistics> References: <1139585230.7561.4.camel@logistics> Message-ID: <20060210154450.GA6519@iam.uni-bonn.de> Hi Dean, * Dean Halter wrote on Fri, Feb 10, 2006 at 04:27:10PM CET: > Hi. I recently downloaded the splint tarball and configured it per the > instructions for a Solaris installation. When i run 'gmake install', it > gives me the following error: > > # gmake install > cd . && /bin/bash /home/cpsadmin/splint-3.1.1/config/missing --run > aclocal-1.6 > /home/cpsadmin/splint-3.1.1/config/missing: line 46: aclocal-1.6: > command not found With a normal tarball, aclocal should not be called at all. This is usually a sign that some time stamps are screwed up, and 'make' thinks some of the autotools-generated files have to be rebuilt. > The aclocal version installed is 1.8.3. I see, from the Jan 2004 > archives, this was discussed. Anyone ever come up with a formal > solution? Thanks in advance. Well, the 'missing' script should take care that the build still completes, even without the program installed: it will touch the to-be-regenerated files. Split should still work as designed, only changes you may have made to files that are input to autoconf and automake won't be updated. Cheers, Ralf From venkiah at ensea.fr Fri Feb 10 10:58:30 2006 From: venkiah at ensea.fr (Auguste Venkiah) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Re: Problem with free In-Reply-To: <1139578250.13122.69.camel@idefix.ensea.fr> References: <1139578250.13122.69.camel@idefix.ensea.fr> Message-ID: <1139587110.13122.79.camel@idefix.ensea.fr> Hello, I am a new user of splint, and I am stuck with this problem. I can't get rid of "storage leak due to incomplete deallocation ..." warnings when I call a function in order to free some memory allocated by malloc. Basically, this is my problem (in a toy example): %----------------------------------------------- #include typedef struct { int *x1; int *x2; }point_t ; void AllocPoint (/*@out@*/ point_t *P) { P->x1 = calloc((size_t)(4), sizeof(int)); P->x2 = calloc((size_t)(4), sizeof(int)); } void FreePoint (point_t *P) { free (P->x1); free (P->x2); } int main (void) { point_t P; AllocPoint(&P); FreePoint(&P); return (1); } %----------------------------------------------- I get this warning : Only storage P.x1 (type int *) derived from variable declared in this scope is not released (memory leak) How can I annotate to tell splint that my function FreePoint is in charge of releasing memory ? I tried -- void FreePoint (/*@keep@*/ point_t *P) --, but it seems that I misunderstand the meaning of the 'keep' annotation. Thank you very much for your help. Auguste From ptp at lysator.liu.se Fri Feb 10 12:23:40 2006 From: ptp at lysator.liu.se (Tommy Pettersson) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Re: Problem with free In-Reply-To: <1139587110.13122.79.camel@idefix.ensea.fr> References: <1139578250.13122.69.camel@idefix.ensea.fr> <1139587110.13122.79.camel@idefix.ensea.fr> Message-ID: <20060210172340.GA4694@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> On Fri, Feb 10, 2006 at 04:58:30PM +0100, Auguste Venkiah wrote: > How can I annotate to tell splint that my function FreePoint is in > charge of releasing memory ? void FreePoint (/*@special@*/ point_t *P) /*@releases P->x1, P->x2 @*/ Section 7.4 in the manual. -- Tommy Pettersson From venkiah at ensea.fr Mon Feb 13 04:18:35 2006 From: venkiah at ensea.fr (Auguste Venkiah) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Re: Problem with free In-Reply-To: <20060210172340.GA4694@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> References: <1139578250.13122.69.camel@idefix.ensea.fr> <1139587110.13122.79.camel@idefix.ensea.fr> <20060210172340.GA4694@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> Message-ID: <1139822315.16800.51.camel@idefix.ensea.fr> Thank you very much :D... I was stuck in section 5 and appendix C of the manual ... :S Le ven 10/02/2006 ? 18:23, Tommy Pettersson a ?crit : > On Fri, Feb 10, 2006 at 04:58:30PM +0100, Auguste Venkiah wrote: > > How can I annotate to tell splint that my function FreePoint is in > > charge of releasing memory ? > > void FreePoint (/*@special@*/ point_t *P) /*@releases P->x1, P->x2 @*/ > > Section 7.4 in the manual. > From jagannath.sahoo at gmail.com Wed Feb 22 01:30:23 2006 From: jagannath.sahoo at gmail.com (jagannath sahoo) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Reg : Splint usage for Kernel module compilation Message-ID: Hi, I am trying to use the splint for checking the driver modules written for MPC5200. My host is i386 architecture. I used the splint through -I flag. and i am including the kernel hearer files meant for powerpc. During general compilation, my module is not giving any error. but if i am checking through splint, it is giving warnings as ../Eaton/denx-2.4.25/src/linux/include/linux/affs_fs_sb.h:19:49: Comment starts inside comment A comment open sequence (/*) appears within a comment. This usually means an earlier comment was not closed. (Use -nestcomment to inhibit warning) In file included from ../Eaton/denx-2.4.25/src/linux/include//linux/fs.h:721, from pwmdriver.c:34 ../Eaton/denx-2.4.25/src/linux/include/asm/types.h:6:24: Parse Error: Suspect missing struct or union keyword: __signed__ : struct { int [2] val; }. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. If i am trying to check a simple application through splint, it is not giving any error. I checked the mailing list. but there one method is mentioned in the following link for using the splint for kernel modules. http://www.splint.org/pipermail/splint-discuss/2005-January/000528.html But, i couldnt know how to use this make file. I want to know, can i check the kernel module written for a different architecture through splint. If it is possible, plz give me some hints. Thanks in advance Sahoo From michele.zamparelli at eso.org Wed Feb 22 11:26:12 2006 From: michele.zamparelli at eso.org (Michele Zamparelli) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] severity levels for splint warnings Message-ID: <43FC90A4.8040506@eso.org> Hallo, I would like to know whether there are some plans to categorize the warnings reported by splint. At least having an error code associated with each reported warning would help a lot, since it would allow individual users to assign codes to severities and use this information for filtering the reporting. We're starting to use splint in an automated framework which roughly works as: 1) checkout the code 2) apply splint on it 3) record the number of warnings in a database. but our developers are saying that some warning are more important than others. How do other people address this problem ? thanks Michele From brian.quinlan at iolfree.ie Wed Feb 22 19:41:32 2006 From: brian.quinlan at iolfree.ie (Brian Quinlan) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Reg : Splint usage for Kernel module compilation In-Reply-To: References: Message-ID: <1140655292.21369.44.camel@akebono> On Wed, 2006-02-22 at 12:00 +0530, jagannath sahoo wrote: > Hi, > I am trying to use the splint for checking the driver modules > written for MPC5200. My host is i386 architecture. I used the splint > through -I flag. and i am including the kernel hearer files meant for > powerpc. During general compilation, my module is not giving any > error. but if i am checking through splint, it is giving warnings as > > ../Eaton/denx-2.4.25/src/linux/include/linux/affs_fs_sb.h:19:49: > Comment starts inside comment > A comment open sequence (/*) appears within a comment. This usually means an > earlier comment was not closed. (Use -nestcomment to inhibit warning) Splint's warning tells you to use -nestcomment for this. > In file included from ../Eaton/denx-2.4.25/src/linux/include//linux/fs.h:721, > from pwmdriver.c:34 > ../Eaton/denx-2.4.25/src/linux/include/asm/types.h:6:24: Parse Error: > Suspect missing struct or union keyword: __signed__ : struct { int [2] val; > }. (For help on parse errors, see splint -help parseerrors.) > *** Cannot continue. > > This warning is one of the warnings addressed by the Makefile in the post that you link to. You need to add -D__signed__=signed to your splint command-line. This strategy (redefining the troublesome code via macros) can be reused to get around other parse errors also. Your target and host architectures should make very little difference to splint. If you have specific splint-related questions about the Makefile, I can try to answer them, but your question is currently too broad to answer. BTW, you don't have to use a Makefile. We did use a Makefile, so that's what I posted. Any method you have of building a splint command-line that defines macros via the -D option will work. Bye, Brian > If i am trying to check a simple application through splint, it is > not giving any error. > > I checked the mailing list. but there one method is mentioned in the > following link for using the splint for kernel modules. > > http://www.splint.org/pipermail/splint-discuss/2005-January/000528.html > > But, i couldnt know how to use this make file. > > I want to know, can i check the kernel module written for a different > architecture through splint. If it is possible, plz give me some > hints. > > Thanks in advance > Sahoo > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From sr7 at agere.com Fri Feb 24 08:00:02 2006 From: sr7 at agere.com (Rothweiler, Steven (Steve)) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning Message-ID: <09884082883D33409956A99BE9F49C1CCEEBAE@PAUMAILU01.ags.agere.com> Hi, This warning seems really silly to me: $ cat splint_test.c static void function(/*@null@*/ /*@out@*/ int* pNullOutParam); int main(void) { int notnull; function(¬null); return 0; } static void function(int* pNullOutParam) { if (!pNullOutParam) { return; } *pNullOutParam = 3; return; } $ splint splint_test.c Splint 3.1.1 --- 19 Aug 2005 splint_test.c: (in function function) splint_test.c:19:16: Out storage pNullOutParam not defined before return An out parameter or global is not defined before control is transferred. (Use -mustdefine to inhibit warning) Finished checking --- 1 code warning $ It seems silly to me because the obvious way of fixing this is to assign a value to *pNullOutParam before returning, but of course, that is impossible, since pNullOutParam is NULL. Obviously, the following definition of function() fixes it, but if instead of *pNullOutParam = 3; I had much more complicated code, then one more level of indentation is really annoying, and in fact, undesirable. static void function(int* pNullOutParam) { if (pNullOutParam) { *pNullOutParam = 3; } return; } Why am I not allowed to check my output parameters for null, then return before I perform the logic that I really care about? Could this be considered a bug in splint? It seems illogical to me to complain about not defining storage whose pointer is NULL. It also seems like it could be a relatively easy bug to fix in splint. -- STeve From jon.wilson at globalgraphics.com Fri Feb 24 08:19:53 2006 From: jon.wilson at globalgraphics.com (Jon Wilson) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning In-Reply-To: <09884082883D33409956A99BE9F49C1CCEEBAE@PAUMAILU01.ags.agere.com> References: <09884082883D33409956A99BE9F49C1CCEEBAE@PAUMAILU01.ags.agere.com> Message-ID: <43FF07F9.7050409@globalgraphics.com> Rothweiler, Steven (Steve) wrote: > Hi, > > This warning seems really silly to me: > > $ cat splint_test.c > > static void > function(/*@null@*/ /*@out@*/ int* pNullOutParam); > > int > main(void) > { > int notnull; > function(¬null); > return 0; > } > > static void > function(int* pNullOutParam) > { > if (!pNullOutParam) > { > return; > } > > *pNullOutParam = 3; > > return; > } > > $ splint splint_test.c > Splint 3.1.1 --- 19 Aug 2005 > > splint_test.c: (in function function) > splint_test.c:19:16: Out storage pNullOutParam not defined before > return > An out parameter or global is not defined before control is > transferred. > (Use -mustdefine to inhibit warning) > > Finished checking --- 1 code warning > > $ > > It seems silly to me because the obvious way of fixing this is to > assign a value to *pNullOutParam before returning, but of course, > that is impossible, since pNullOutParam is NULL. > > Obviously, the following definition of function() fixes it, but if > instead of *pNullOutParam = 3; I had much more complicated code, > then one more level of indentation is really annoying, and in fact, > undesirable. > > static void > function(int* pNullOutParam) > { > if (pNullOutParam) > { > *pNullOutParam = 3; > } > > return; > } > > Why am I not allowed to check my output parameters for null, then > return before I perform the logic that I really care about? > > Could this be considered a bug in splint? It seems illogical to me > to complain about not defining storage whose pointer is NULL. It > also seems like it could be a relatively easy bug to fix in splint. > -- > STeve It seems like all you're surprised about is the fact that the @out@ takes precedence over the @null@. You are specifying that *pNullOutParam is always defined on exit, which doesn't make sense when pNullOutParam can be null. I suppose the only other sensible way for splint to act would be for it to complain that you can't have it both ways, or maybe to add another annotation that says "it's defined if it's there to be defined". The way I've designed around this, which actually makes for cleaner code in my view, is to move the responsibility for null checking into the caller and annotating such interfaces with @notnull@. In fact that can work out marginally more efficient because the check for null can often be hoisted quite high in the call chain and then subroutines can assert for non-null rather than test for it - along with the safety backstop of Splint complaining if the @notnull@ is violated. Jon From jon.wilson at globalgraphics.com Fri Feb 24 08:19:53 2006 From: jon.wilson at globalgraphics.com (Jon Wilson) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning In-Reply-To: <09884082883D33409956A99BE9F49C1CCEEBAE@PAUMAILU01.ags.agere.com> References: <09884082883D33409956A99BE9F49C1CCEEBAE@PAUMAILU01.ags.agere.com> Message-ID: <43FF07F9.7050409@globalgraphics.com> Rothweiler, Steven (Steve) wrote: > Hi, > > This warning seems really silly to me: > > $ cat splint_test.c > > static void > function(/*@null@*/ /*@out@*/ int* pNullOutParam); > > int > main(void) > { > int notnull; > function(¬null); > return 0; > } > > static void > function(int* pNullOutParam) > { > if (!pNullOutParam) > { > return; > } > > *pNullOutParam = 3; > > return; > } > > $ splint splint_test.c > Splint 3.1.1 --- 19 Aug 2005 > > splint_test.c: (in function function) > splint_test.c:19:16: Out storage pNullOutParam not defined before > return > An out parameter or global is not defined before control is > transferred. > (Use -mustdefine to inhibit warning) > > Finished checking --- 1 code warning > > $ > > It seems silly to me because the obvious way of fixing this is to > assign a value to *pNullOutParam before returning, but of course, > that is impossible, since pNullOutParam is NULL. > > Obviously, the following definition of function() fixes it, but if > instead of *pNullOutParam = 3; I had much more complicated code, > then one more level of indentation is really annoying, and in fact, > undesirable. > > static void > function(int* pNullOutParam) > { > if (pNullOutParam) > { > *pNullOutParam = 3; > } > > return; > } > > Why am I not allowed to check my output parameters for null, then > return before I perform the logic that I really care about? > > Could this be considered a bug in splint? It seems illogical to me > to complain about not defining storage whose pointer is NULL. It > also seems like it could be a relatively easy bug to fix in splint. > -- > STeve It seems like all you're surprised about is the fact that the @out@ takes precedence over the @null@. You are specifying that *pNullOutParam is always defined on exit, which doesn't make sense when pNullOutParam can be null. I suppose the only other sensible way for splint to act would be for it to complain that you can't have it both ways, or maybe to add another annotation that says "it's defined if it's there to be defined". The way I've designed around this, which actually makes for cleaner code in my view, is to move the responsibility for null checking into the caller and annotating such interfaces with @notnull@. In fact that can work out marginally more efficient because the check for null can often be hoisted quite high in the call chain and then subroutines can assert for non-null rather than test for it - along with the safety backstop of Splint complaining if the @notnull@ is violated. Jon From sr7 at agere.com Fri Feb 24 08:25:46 2006 From: sr7 at agere.com (Rothweiler, Steven (Steve)) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning Message-ID: <09884082883D33409956A99BE9F49C1CCEEBB1@PAUMAILU01.ags.agere.com> Jon, First of all, null and out are allowed together, so splint should handle it. Second, if function() is an API that your customers are going to be calling, you cannot trust them to not pass you NULL, even if you say /*@notnull@*/. Third, I tried swapping null and out, but the order seems to be immaterial. -- STeve -----Original Message----- From: splint-discuss-bounces@cs.virginia.edu [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson Sent: Friday, February 24, 2006 8:20 AM To: Discussions about the Splint annotation-assisted static analysis project Cc: splint-discuss@ares.cs.Virginia.EDU Subject: Re: [splint-discuss] Silly splint warning Rothweiler, Steven (Steve) wrote: > Hi, > > This warning seems really silly to me: > > $ cat splint_test.c > > static void > function(/*@null@*/ /*@out@*/ int* pNullOutParam); > > int > main(void) > { > int notnull; > function(¬null); > return 0; > } > > static void > function(int* pNullOutParam) > { > if (!pNullOutParam) > { > return; > } > > *pNullOutParam = 3; > > return; > } > > $ splint splint_test.c > Splint 3.1.1 --- 19 Aug 2005 > > splint_test.c: (in function function) > splint_test.c:19:16: Out storage pNullOutParam not defined before > return > An out parameter or global is not defined before control is > transferred. > (Use -mustdefine to inhibit warning) > > Finished checking --- 1 code warning > > $ > > It seems silly to me because the obvious way of fixing this is to > assign a value to *pNullOutParam before returning, but of course, > that is impossible, since pNullOutParam is NULL. > > Obviously, the following definition of function() fixes it, but if > instead of *pNullOutParam = 3; I had much more complicated code, > then one more level of indentation is really annoying, and in fact, > undesirable. > > static void > function(int* pNullOutParam) > { > if (pNullOutParam) > { > *pNullOutParam = 3; > } > > return; > } > > Why am I not allowed to check my output parameters for null, then > return before I perform the logic that I really care about? > > Could this be considered a bug in splint? It seems illogical to me > to complain about not defining storage whose pointer is NULL. It > also seems like it could be a relatively easy bug to fix in splint. > -- > STeve It seems like all you're surprised about is the fact that the @out@ takes precedence over the @null@. You are specifying that *pNullOutParam is always defined on exit, which doesn't make sense when pNullOutParam can be null. I suppose the only other sensible way for splint to act would be for it to complain that you can't have it both ways, or maybe to add another annotation that says "it's defined if it's there to be defined". The way I've designed around this, which actually makes for cleaner code in my view, is to move the responsibility for null checking into the caller and annotating such interfaces with @notnull@. In fact that can work out marginally more efficient because the check for null can often be hoisted quite high in the call chain and then subroutines can assert for non-null rather than test for it - along with the safety backstop of Splint complaining if the @notnull@ is violated. Jon _______________________________________________ splint-discuss mailing list splint-discuss@ares.cs.Virginia.EDU http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From sr7 at agere.com Fri Feb 24 08:25:46 2006 From: sr7 at agere.com (Rothweiler, Steven (Steve)) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning Message-ID: <09884082883D33409956A99BE9F49C1CCEEBB1@PAUMAILU01.ags.agere.com> Jon, First of all, null and out are allowed together, so splint should handle it. Second, if function() is an API that your customers are going to be calling, you cannot trust them to not pass you NULL, even if you say /*@notnull@*/. Third, I tried swapping null and out, but the order seems to be immaterial. -- STeve -----Original Message----- From: splint-discuss-bounces@cs.virginia.edu [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson Sent: Friday, February 24, 2006 8:20 AM To: Discussions about the Splint annotation-assisted static analysis project Cc: splint-discuss@ares.cs.Virginia.EDU Subject: Re: [splint-discuss] Silly splint warning Rothweiler, Steven (Steve) wrote: > Hi, > > This warning seems really silly to me: > > $ cat splint_test.c > > static void > function(/*@null@*/ /*@out@*/ int* pNullOutParam); > > int > main(void) > { > int notnull; > function(¬null); > return 0; > } > > static void > function(int* pNullOutParam) > { > if (!pNullOutParam) > { > return; > } > > *pNullOutParam = 3; > > return; > } > > $ splint splint_test.c > Splint 3.1.1 --- 19 Aug 2005 > > splint_test.c: (in function function) > splint_test.c:19:16: Out storage pNullOutParam not defined before > return > An out parameter or global is not defined before control is > transferred. > (Use -mustdefine to inhibit warning) > > Finished checking --- 1 code warning > > $ > > It seems silly to me because the obvious way of fixing this is to > assign a value to *pNullOutParam before returning, but of course, > that is impossible, since pNullOutParam is NULL. > > Obviously, the following definition of function() fixes it, but if > instead of *pNullOutParam = 3; I had much more complicated code, > then one more level of indentation is really annoying, and in fact, > undesirable. > > static void > function(int* pNullOutParam) > { > if (pNullOutParam) > { > *pNullOutParam = 3; > } > > return; > } > > Why am I not allowed to check my output parameters for null, then > return before I perform the logic that I really care about? > > Could this be considered a bug in splint? It seems illogical to me > to complain about not defining storage whose pointer is NULL. It > also seems like it could be a relatively easy bug to fix in splint. > -- > STeve It seems like all you're surprised about is the fact that the @out@ takes precedence over the @null@. You are specifying that *pNullOutParam is always defined on exit, which doesn't make sense when pNullOutParam can be null. I suppose the only other sensible way for splint to act would be for it to complain that you can't have it both ways, or maybe to add another annotation that says "it's defined if it's there to be defined". The way I've designed around this, which actually makes for cleaner code in my view, is to move the responsibility for null checking into the caller and annotating such interfaces with @notnull@. In fact that can work out marginally more efficient because the check for null can often be hoisted quite high in the call chain and then subroutines can assert for non-null rather than test for it - along with the safety backstop of Splint complaining if the @notnull@ is violated. Jon _______________________________________________ splint-discuss mailing list splint-discuss@ares.cs.Virginia.EDU http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From jon.wilson at globalgraphics.com Fri Feb 24 08:33:52 2006 From: jon.wilson at globalgraphics.com (Jon Wilson) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning In-Reply-To: <09884082883D33409956A99BE9F49C1CCEEBB1@PAUMAILU01.ags.agere.com> References: <09884082883D33409956A99BE9F49C1CCEEBB1@PAUMAILU01.ags.agere.com> Message-ID: <43FF0B40.308@globalgraphics.com> Rothweiler, Steven (Steve) wrote: > Jon, > > First of all, null and out are allowed together, so splint > should handle it. Which is why I mentioned that one option would be for Splint to refuse to handle it, because they are mutually exclusive. > Second, if function() is an API that your customers are going > to be calling, you cannot trust them to not pass you NULL, even > if you say /*@notnull@*/. Unless the customers are also going to use Splint, the @out@ annotation means nothing anyway in that case. > Third, I tried swapping null and out, but the order seems to be > immaterial. > -- > STeve > > > -----Original Message----- > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson > Sent: Friday, February 24, 2006 8:20 AM > To: Discussions about the Splint annotation-assisted static analysis > project > Cc: splint-discuss@ares.cs.Virginia.EDU > Subject: Re: [splint-discuss] Silly splint warning > > > Rothweiler, Steven (Steve) wrote: >> Hi, >> >> This warning seems really silly to me: >> >> $ cat splint_test.c >> >> static void >> function(/*@null@*/ /*@out@*/ int* pNullOutParam); >> >> int >> main(void) >> { >> int notnull; >> function(¬null); >> return 0; >> } >> >> static void >> function(int* pNullOutParam) >> { >> if (!pNullOutParam) >> { >> return; >> } >> >> *pNullOutParam = 3; >> >> return; >> } >> >> $ splint splint_test.c >> Splint 3.1.1 --- 19 Aug 2005 >> >> splint_test.c: (in function function) >> splint_test.c:19:16: Out storage pNullOutParam not defined before >> return >> An out parameter or global is not defined before control is >> transferred. >> (Use -mustdefine to inhibit warning) >> >> Finished checking --- 1 code warning >> >> $ >> >> It seems silly to me because the obvious way of fixing this is to >> assign a value to *pNullOutParam before returning, but of course, >> that is impossible, since pNullOutParam is NULL. >> >> Obviously, the following definition of function() fixes it, but if >> instead of *pNullOutParam = 3; I had much more complicated code, >> then one more level of indentation is really annoying, and in fact, >> undesirable. >> >> static void >> function(int* pNullOutParam) >> { >> if (pNullOutParam) >> { >> *pNullOutParam = 3; >> } >> >> return; >> } >> >> Why am I not allowed to check my output parameters for null, then >> return before I perform the logic that I really care about? >> >> Could this be considered a bug in splint? It seems illogical to me >> to complain about not defining storage whose pointer is NULL. It >> also seems like it could be a relatively easy bug to fix in splint. >> -- >> STeve > > It seems like all you're surprised about is the fact that the @out@ > takes precedence over the @null@. You are specifying that *pNullOutParam > > is always defined on exit, which doesn't make sense when pNullOutParam > can be null. I suppose the only other sensible way for splint to act > would be for it to complain that you can't have it both ways, or maybe > to add another annotation that says "it's defined if it's there to be > defined". > > The way I've designed around this, which actually makes for cleaner code > > in my view, is to move the responsibility for null checking into the > caller and annotating such interfaces with @notnull@. In fact that can > work out marginally more efficient because the check for null can often > be hoisted quite high in the call chain and then subroutines can assert > for non-null rather than test for it - along with the safety backstop of > > Splint complaining if the @notnull@ is violated. > > Jon > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From jon.wilson at globalgraphics.com Fri Feb 24 08:33:52 2006 From: jon.wilson at globalgraphics.com (Jon Wilson) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning In-Reply-To: <09884082883D33409956A99BE9F49C1CCEEBB1@PAUMAILU01.ags.agere.com> References: <09884082883D33409956A99BE9F49C1CCEEBB1@PAUMAILU01.ags.agere.com> Message-ID: <43FF0B40.308@globalgraphics.com> Rothweiler, Steven (Steve) wrote: > Jon, > > First of all, null and out are allowed together, so splint > should handle it. Which is why I mentioned that one option would be for Splint to refuse to handle it, because they are mutually exclusive. > Second, if function() is an API that your customers are going > to be calling, you cannot trust them to not pass you NULL, even > if you say /*@notnull@*/. Unless the customers are also going to use Splint, the @out@ annotation means nothing anyway in that case. > Third, I tried swapping null and out, but the order seems to be > immaterial. > -- > STeve > > > -----Original Message----- > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson > Sent: Friday, February 24, 2006 8:20 AM > To: Discussions about the Splint annotation-assisted static analysis > project > Cc: splint-discuss@ares.cs.Virginia.EDU > Subject: Re: [splint-discuss] Silly splint warning > > > Rothweiler, Steven (Steve) wrote: >> Hi, >> >> This warning seems really silly to me: >> >> $ cat splint_test.c >> >> static void >> function(/*@null@*/ /*@out@*/ int* pNullOutParam); >> >> int >> main(void) >> { >> int notnull; >> function(¬null); >> return 0; >> } >> >> static void >> function(int* pNullOutParam) >> { >> if (!pNullOutParam) >> { >> return; >> } >> >> *pNullOutParam = 3; >> >> return; >> } >> >> $ splint splint_test.c >> Splint 3.1.1 --- 19 Aug 2005 >> >> splint_test.c: (in function function) >> splint_test.c:19:16: Out storage pNullOutParam not defined before >> return >> An out parameter or global is not defined before control is >> transferred. >> (Use -mustdefine to inhibit warning) >> >> Finished checking --- 1 code warning >> >> $ >> >> It seems silly to me because the obvious way of fixing this is to >> assign a value to *pNullOutParam before returning, but of course, >> that is impossible, since pNullOutParam is NULL. >> >> Obviously, the following definition of function() fixes it, but if >> instead of *pNullOutParam = 3; I had much more complicated code, >> then one more level of indentation is really annoying, and in fact, >> undesirable. >> >> static void >> function(int* pNullOutParam) >> { >> if (pNullOutParam) >> { >> *pNullOutParam = 3; >> } >> >> return; >> } >> >> Why am I not allowed to check my output parameters for null, then >> return before I perform the logic that I really care about? >> >> Could this be considered a bug in splint? It seems illogical to me >> to complain about not defining storage whose pointer is NULL. It >> also seems like it could be a relatively easy bug to fix in splint. >> -- >> STeve > > It seems like all you're surprised about is the fact that the @out@ > takes precedence over the @null@. You are specifying that *pNullOutParam > > is always defined on exit, which doesn't make sense when pNullOutParam > can be null. I suppose the only other sensible way for splint to act > would be for it to complain that you can't have it both ways, or maybe > to add another annotation that says "it's defined if it's there to be > defined". > > The way I've designed around this, which actually makes for cleaner code > > in my view, is to move the responsibility for null checking into the > caller and annotating such interfaces with @notnull@. In fact that can > work out marginally more efficient because the check for null can often > be hoisted quite high in the call chain and then subroutines can assert > for non-null rather than test for it - along with the safety backstop of > > Splint complaining if the @notnull@ is violated. > > Jon > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From sr7 at agere.com Fri Feb 24 08:45:17 2006 From: sr7 at agere.com (Rothweiler, Steven (Steve)) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning Message-ID: <09884082883D33409956A99BE9F49C1CCEEBB7@PAUMAILU01.ags.agere.com> Jon, I'm not suggesting that /*@null@*/ and /*@out@*/ be mutually exclusive. In fact, I don't think there's any problem at all with them being used together. Why can't splint understand that when a pointer is NULL, there's no need to define the storage to which it points? It seems to me that there is much deeper understanding designed into the program than this simple concept. Also, I've noticed that if I don't specify /*@null@*/, and so by default it is /*@notnull@*/, and if I go ahead and check the pointer for NULL, splint assumes from that point on that the pointer could be NULL, as if I had specified that it could be. In addition, splint knows inside tests for NULL and non-NULL, that the pointer is indeed NULL or not NULL, so that it can complain about various other things. So it still seems silly to me, if not a bug. -- STeve -----Original Message----- From: splint-discuss-bounces@cs.virginia.edu [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson Sent: Friday, February 24, 2006 8:34 AM To: Discussions about the Splint annotation-assisted static analysis project Cc: splint-discuss@ares.cs.Virginia.EDU Subject: Re: [splint-discuss] Silly splint warning Rothweiler, Steven (Steve) wrote: > Jon, > > First of all, null and out are allowed together, so splint > should handle it. Which is why I mentioned that one option would be for Splint to refuse to handle it, because they are mutually exclusive. > Second, if function() is an API that your customers are going > to be calling, you cannot trust them to not pass you NULL, even > if you say /*@notnull@*/. Unless the customers are also going to use Splint, the @out@ annotation means nothing anyway in that case. > Third, I tried swapping null and out, but the order seems to be > immaterial. > -- > STeve > > > -----Original Message----- > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson > Sent: Friday, February 24, 2006 8:20 AM > To: Discussions about the Splint annotation-assisted static analysis > project > Cc: splint-discuss@ares.cs.Virginia.EDU > Subject: Re: [splint-discuss] Silly splint warning > > > Rothweiler, Steven (Steve) wrote: >> Hi, >> >> This warning seems really silly to me: >> >> $ cat splint_test.c >> >> static void >> function(/*@null@*/ /*@out@*/ int* pNullOutParam); >> >> int >> main(void) >> { >> int notnull; >> function(¬null); >> return 0; >> } >> >> static void >> function(int* pNullOutParam) >> { >> if (!pNullOutParam) >> { >> return; >> } >> >> *pNullOutParam = 3; >> >> return; >> } >> >> $ splint splint_test.c >> Splint 3.1.1 --- 19 Aug 2005 >> >> splint_test.c: (in function function) >> splint_test.c:19:16: Out storage pNullOutParam not defined before >> return >> An out parameter or global is not defined before control is >> transferred. >> (Use -mustdefine to inhibit warning) >> >> Finished checking --- 1 code warning >> >> $ >> >> It seems silly to me because the obvious way of fixing this is to >> assign a value to *pNullOutParam before returning, but of course, >> that is impossible, since pNullOutParam is NULL. >> >> Obviously, the following definition of function() fixes it, but if >> instead of *pNullOutParam = 3; I had much more complicated code, >> then one more level of indentation is really annoying, and in fact, >> undesirable. >> >> static void >> function(int* pNullOutParam) >> { >> if (pNullOutParam) >> { >> *pNullOutParam = 3; >> } >> >> return; >> } >> >> Why am I not allowed to check my output parameters for null, then >> return before I perform the logic that I really care about? >> >> Could this be considered a bug in splint? It seems illogical to me >> to complain about not defining storage whose pointer is NULL. It >> also seems like it could be a relatively easy bug to fix in splint. >> -- >> STeve > > It seems like all you're surprised about is the fact that the @out@ > takes precedence over the @null@. You are specifying that *pNullOutParam > > is always defined on exit, which doesn't make sense when pNullOutParam > can be null. I suppose the only other sensible way for splint to act > would be for it to complain that you can't have it both ways, or maybe > to add another annotation that says "it's defined if it's there to be > defined". > > The way I've designed around this, which actually makes for cleaner code > > in my view, is to move the responsibility for null checking into the > caller and annotating such interfaces with @notnull@. In fact that can > work out marginally more efficient because the check for null can often > be hoisted quite high in the call chain and then subroutines can assert > for non-null rather than test for it - along with the safety backstop of > > Splint complaining if the @notnull@ is violated. > > Jon > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss _______________________________________________ splint-discuss mailing list splint-discuss@ares.cs.Virginia.EDU http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From sr7 at agere.com Fri Feb 24 08:45:17 2006 From: sr7 at agere.com (Rothweiler, Steven (Steve)) Date: Wed Mar 22 17:11:25 2006 Subject: [splint-discuss] Silly splint warning Message-ID: <09884082883D33409956A99BE9F49C1CCEEBB7@PAUMAILU01.ags.agere.com> Jon, I'm not suggesting that /*@null@*/ and /*@out@*/ be mutually exclusive. In fact, I don't think there's any problem at all with them being used together. Why can't splint understand that when a pointer is NULL, there's no need to define the storage to which it points? It seems to me that there is much deeper understanding designed into the program than this simple concept. Also, I've noticed that if I don't specify /*@null@*/, and so by default it is /*@notnull@*/, and if I go ahead and check the pointer for NULL, splint assumes from that point on that the pointer could be NULL, as if I had specified that it could be. In addition, splint knows inside tests for NULL and non-NULL, that the pointer is indeed NULL or not NULL, so that it can complain about various other things. So it still seems silly to me, if not a bug. -- STeve -----Original Message----- From: splint-discuss-bounces@cs.virginia.edu [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson Sent: Friday, February 24, 2006 8:34 AM To: Discussions about the Splint annotation-assisted static analysis project Cc: splint-discuss@ares.cs.Virginia.EDU Subject: Re: [splint-discuss] Silly splint warning Rothweiler, Steven (Steve) wrote: > Jon, > > First of all, null and out are allowed together, so splint > should handle it. Which is why I mentioned that one option would be for Splint to refuse to handle it, because they are mutually exclusive. > Second, if function() is an API that your customers are going > to be calling, you cannot trust them to not pass you NULL, even > if you say /*@notnull@*/. Unless the customers are also going to use Splint, the @out@ annotation means nothing anyway in that case. > Third, I tried swapping null and out, but the order seems to be > immaterial. > -- > STeve > > > -----Original Message----- > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Jon Wilson > Sent: Friday, February 24, 2006 8:20 AM > To: Discussions about the Splint annotation-assisted static analysis > project > Cc: splint-discuss@ares.cs.Virginia.EDU > Subject: Re: [splint-discuss] Silly splint warning > > > Rothweiler, Steven (Steve) wrote: >> Hi, >> >> This warning seems really silly to me: >> >> $ cat splint_test.c >> >> static void >> function(/*@null@*/ /*@out@*/ int* pNullOutParam); >> >> int >> main(void) >> { >> int notnull; >> function(¬null); >> return 0; >> } >> >> static void >> function(int* pNullOutParam) >> { >> if (!pNullOutParam) >> { >> return; >> } >> >> *pNullOutParam = 3; >> >> return; >> } >> >> $ splint splint_test.c >> Splint 3.1.1 --- 19 Aug 2005 >> >> splint_test.c: (in function function) >> splint_test.c:19:16: Out storage pNullOutParam not defined before >> return >> An out parameter or global is not defined before control is >> transferred. >> (Use -mustdefine to inhibit warning) >> >> Finished checking --- 1 code warning >> >> $ >> >> It seems silly to me because the obvious way of fixing this is to >> assign a value to *pNullOutParam before returning, but of course, >> that is impossible, since pNullOutParam is NULL. >> >> Obviously, the following definition of function() fixes it, but if >> instead of *pNullOutParam = 3; I had much more complicated code, >> then one more level of indentation is really annoying, and in fact, >> undesirable. >> >> static void >> function(int* pNullOutParam) >> { >> if (pNullOutParam) >> { >> *pNullOutParam = 3; >> } >> >> return; >> } >> >> Why am I not allowed to check my output parameters for null, then >> return before I perform the logic that I really care about? >> >> Could this be considered a bug in splint? It seems illogical to me >> to complain about not defining storage whose pointer is NULL. It >> also seems like it could be a relatively easy bug to fix in splint. >> -- >> STeve > > It seems like all you're surprised about is the fact that the @out@ > takes precedence over the @null@. You are specifying that *pNullOutParam > > is always defined on exit, which doesn't make sense when pNullOutParam > can be null. I suppose the only other sensible way for splint to act > would be for it to complain that you can't have it both ways, or maybe > to add another annotation that says "it's defined if it's there to be > defined". > > The way I've designed around this, which actually makes for cleaner code > > in my view, is to move the responsibility for null checking into the > caller and annotating such interfaces with @notnull@. In fact that can > work out marginally more efficient because the check for null can often > be hoisted quite high in the call chain and then subroutines can assert > for non-null rather than test for it - along with the safety backstop of > > Splint complaining if the @notnull@ is violated. > > Jon > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss _______________________________________________ splint-discuss mailing list splint-discuss@ares.cs.Virginia.EDU http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss