From chifflier at cpe.fr Thu Oct 2 05:57:08 2003 From: chifflier at cpe.fr (Pierre Chifflier) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] newbie question: parse error (me too !) Message-ID: <20031002095708.GA26537@image4.cpe.fr> Hi, I'm trying to run splint on my code but always get Parse Errors: splint -weak +posixlib wzd_main.c Splint 3.1.1 --- 17 Sep 2003 /usr/include/arpa/inet.h:35:27: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. [wzdftpd-0.1-cvs/src] sed -n 35p /usr/include/arpa/inet.h extern in_addr_t inet_addr (__const char *__cp) __THROW; I tried to search in the ML archives, there are similar problems but not this one. I precise i'm running a debian system (unstable version), and that my libc6 version is 2.3.2 Thanks /P -- chifflier@cpe.fr BOFH excuse #304: routing problems on the neural net From cbfalconer at yahoo.com Thu Oct 2 09:03:01 2003 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] newbie question: parse error (me too !) References: <20031002095708.GA26537@image4.cpe.fr> Message-ID: <3F7C2205.41773B4B@yahoo.com> Pierre Chifflier wrote: > > I'm trying to run splint on my code but always get Parse Errors: > > splint -weak +posixlib wzd_main.c > Splint 3.1.1 --- 17 Sep 2003 > > /usr/include/arpa/inet.h:35:27: Parse Error. (For help on parse > errors, see > splint -help parseerrors.) > *** Cannot continue. > [wzdftpd-0.1-cvs/src] sed -n 35p /usr/include/arpa/inet.h > extern in_addr_t inet_addr (__const char *__cp) __THROW; That "__THROW" looks very suspicious - it certainly isn't C. Maybe you should define it away? (at least for splint use). Does the code compile, and on what compiler? -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From mne at mosaic-ag.com Thu Oct 2 11:57:02 2003 From: mne at mosaic-ag.com (Miroslaw Dobrzanski-Neumann) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] newbie question: parse error (me too !) In-Reply-To: <3F7C2205.41773B4B@yahoo.com> References: <20031002095708.GA26537@image4.cpe.fr> <3F7C2205.41773B4B@yahoo.com> Message-ID: <20031002155702.GA27490@mailsrv.mosaic-ag.com> On Thu, Oct 02, 2003 at 09:03:01AM -0400, CBFalconer wrote: > Pierre Chifflier wrote: > > > > I'm trying to run splint on my code but always get Parse Errors: > > > > splint -weak +posixlib wzd_main.c > > Splint 3.1.1 --- 17 Sep 2003 > > > > /usr/include/arpa/inet.h:35:27: Parse Error. (For help on parse > > errors, see > > splint -help parseerrors.) > > *** Cannot continue. > > [wzdftpd-0.1-cvs/src] sed -n 35p /usr/include/arpa/inet.h > > extern in_addr_t inet_addr (__const char *__cp) __THROW; > > That "__THROW" looks very suspicious - it certainly isn't C. > Maybe you should define it away? (at least for splint use). Does > the code compile, and on what compiler? #ifdef __cplusplus #define __THROW throw () #endif #define __THROW #endif This accepts every C compiler; in C++ context the declaration says, that the called function throws no exception so some pieces of stack unwind code can be safely omited Regards -- Miros?aw Dobrza?ski-Neumann E-mail: mne@mosaic-ag.com This message is utf-8 encoded From khindenburg at cherrynebula.net Thu Oct 2 13:51:54 2003 From: khindenburg at cherrynebula.net (Kurt V. Hindenburg) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] glib parse errors In-Reply-To: References: <200309132255.37120.khindenburg@cherrynebula.net> Message-ID: <1065117114.3591.20.camel@rachael> On Sun, 2003-09-14 at 19:04, David Evans wrote: > Splint isn't able to parse macros with (...) parameters. > G_HAVE_ISO_VARARGS should not be defined so these macros are not > processed. > > Running splint on a file that just contains #include > works okay for me. Perhaps one of the other include files is defining > G_HAVE_ISO_VARARGS? > > --- Dave O.K. this doesn't appear to be a splint problem, although I can't seem to find out where/if G_HAVE_ISO_VARARGS is getting defined. Here's the actual error : (kvh@rachael)-(12:35)-(~/CVS-gkrellsun/gkrellsun/src20)> ./run_splint gkrellsun.c Splint 3.0.1.6 --- 01 Oct 2003 In file included from usr/include/glib-2.0/glib.h:50, from usr/include/gtk-2.0/gdk/gdktypes.h:32, from usr/include/gtk-2.0/gdk/gdkcolor.h:4, from usr/include/gtk-2.0/gdk/gdk.h:30, from usr/include/gtk-2.0/gtk/gtk.h:31, from usr/include/gkrellm2/gkrellm.h:30, from gkrellsun.c:10 usr/include/glib-2.0/glib/gmessages.h:116:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:116:44: Parameter list for #define is not parseable usr/include/glib-2.0/glib/gmessages.h:119:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:119:44: Parameter list for #define is not parseable usr/include/glib-2.0/glib/gmessages.h:122:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:122:44: Parameter list for #define is not parseable usr/include/glib-2.0/glib/gmessages.h:125:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:125:44: Parameter list for #define is not parseable Preprocessing error for file: /home/kvh/CVS-gkrellsun/gkrellsun/src20/gkrellsun. c *** Cannot continue. % cat run_splint #!/bin/sh NONULL="-nullassign" BOOLINT="+boolint" CHARINT="+charintliteral +charint" MUSTDEFINE="-mustdefine" COMPDEF="-compdef" UNRECOG="-unrecog" NULLPASS="-nullpass" ARGS="${NONULL} ${BOOLINT} ${CHARINT} ${COMPDEF} ${UNRECOG} ${NULLPASS}" splint -I `pkg-config gtk+-2.0 --cflags` $ARGS $1 % pkg-config gtk+-2.0 --cflags -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include From chifflier at cpe.fr Thu Oct 2 16:38:15 2003 From: chifflier at cpe.fr (Pierre Chifflier) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] newbie question: parse error (me too !) In-Reply-To: <3F7C2205.41773B4B@yahoo.com> References: <20031002095708.GA26537@image4.cpe.fr> <3F7C2205.41773B4B@yahoo.com> Message-ID: <20031002203815.GA2802@image4.cpe.fr> On Thu, Oct 02, 2003 at 09:03:01AM -0400, CBFalconer wrote: > > [wzdftpd-0.1-cvs/src] sed -n 35p /usr/include/arpa/inet.h > > extern in_addr_t inet_addr (__const char *__cp) __THROW; > > That "__THROW" looks very suspicious - it certainly isn't C. > Maybe you should define it away? (at least for splint use). Does > the code compile, and on what compiler? Yes, i tried to define it (but i guess that's the compiler does in C) and got the same error again. I'm using gcc, version 2.95, 3.2 or 3.3 - the code always compile correctly and with no warning (-Wall) on linux & *bsd. Is it linked to the version of libc6 ? Does someone have splinted code including arpa/inet.h beforei, but with another libc6 version ? /P -- chifflier@cpe.fr BOFH excuse #386: The Internet is being scanned for viruses. From Marco.Giromini at marconiselenia.com Tue Oct 7 06:03:51 2003 From: Marco.Giromini at marconiselenia.com (Marco.Giromini@marconiselenia.com) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] Problems with target machines where long and int have the same dim. (e.g. 32 bit) Message-ID: ---------------------- Forwarded by Marco Giromini/MAIN/MC1 on 10/07/2003 12:02 PM --------------------------- From: Marco Giromini @ OTE On: 10/03/2003 03:22:16 PM To: splint-bug@splint.org cc: alessandro.coco@isti.cnr.it, fabrizio.fabbrini@isti.cnr.it (bcc: Marco Giromini/MAIN/MC1) Subject: Problems with target machines where long and int have the same dim. (e.g. 32 bit) (Document link: Marco Giromini) Problems with target machines where long and int have the same dim. (e.g. 32 bit): 1) Is it possible to make long and int types equivalent ? I tried with +long-int (although it is not present inside the splint manual), but I received the error message reported below: *** Internal Bug at llerror.c:918: No hint available, flag longintegral is already set. [errno: 25] *** Please report bug to splint-bug@splint.org *** I think it interferes with +long-integral, which I used to "Allow long type to match an arbitrary integral type (e.g., dev_t)" I hope this could be helpful for improving the Splint message. 2) Is it possible to Allow int type (unsigned or signed) to match an arbitrary integral type E.g. I'd like to make size_t (32 bit either if int or long) equivalent to int (32 bit), still getting a warning wrt short int (16 bit) Still useing the following ansi.h definitions (in splint lib): typedef /*@integraltype@*/ ptrdiff_t; typedef /*@unsignedintegraltype@*/ size_t; typedef /*@signedintegraltype@*/ ssize_t; I'd like something like the following (but I know thay are not present inside the splint manual): +int-integral Allow int type to match an arbitrary integral type (e.g., dev_t) +int-unsigned-integral Allow int type to match an arbitrary unsigned integral type (e.g., size_t) +int-signed-integral Allow int type to match an arbitrary signed integral type (e.g., ssize_t). Otherwise I have to disable any warning related to arbitrary integrals, with: match-any-integral Allow any integral type to match an arbitrary 3) I tried to disable signed/unsigned warnings, with: +ignore-signs Ignore signs in type comparisons (unsigned matches signed). Anyway I received the error message reported below: *** Internal Bug at llerror.c:918: No hint available, flag matchanyintegral is already set. [errno: 25] *** Please report bug to splint-bug@splint.org *** I think it interferes with +match-any-integral, which I had to use (see point 2). 4) Last but not least, I do not agree with the following splint manual sentence: relax-quals Report qualifier mismatches only if dangerous (information may be lost since a larger type is assigned to (or passed as) a smaller one or a comparison uses signed and unsigned values.) I get warnings also if: a larger type is compared with a smaller one - E.g. (short int, int) I do not understand why a signed type is assigned to (or passed as) a unsigned one - and viceversa I undestand why, because signed and unsigned do not cover the same range of values Best regards Marco Giromini OTE S.p.A. - A Finmeccanica Company voice: +39-050-3132.473 e-mail: Marco.Giromini@marconiselenia.com From Jay.St.Pierre at Colorado.EDU Wed Oct 8 16:07:25 2003 From: Jay.St.Pierre at Colorado.EDU (Jay A. St. Pierre) Date: Wed Mar 22 17:10:16 2006 Subject: [splint-discuss] real-compare Message-ID: I think that the real-compare check could be improved. For example, consider this piece of code: #include #include int main(void) { double x=1.0e-30; double y=2.0e-30; if (y>x) { printf("Case 1: y > x\n"); } if ( (y-x) > DBL_EPSILON ) { printf("Case 2: y > x\n"); } if ( (y-x) > x*DBL_EPSILON ) { printf("Case 3: y > x\n"); } return(0); } If I run splint on this, I get: Splint 3.1.1 --- 20 May 2003 foo.c: (in function main) foo.c:9:7: Dangerous comparison involving double types: y > x Two real (float, double, or long double) values are compared directly using a C primitive. This may produce unexpected results since floating point representations are inexact. Instead, compare the difference to FLT_EPSILON or DBL_EPSILON. (Use -realcompare to inhibit warning) foo.c:17:8: Dangerous comparison involving double types: (y - x) > x * DBL_EPSILON Finished checking --- 2 code warnings DBL_EPSILON, according to the C99 Standard is 1E-9 or smaller. Even assuming its 2E-16, comparing the difference of x and y above to DBL_EPSILON is useless in determining whether one or the other is greater (as can be seen if you try to compile and run the above program: Case 2 will not be true). Without manually reimplementing the comparison operator so that each step can satisfy splint (progressivly compare signs, exponents, mantissas), a programmer doing many floating point comparisons might as well turn off the real-compare splint flag. However it would be nice to catch and warn about the following comparisons: x == y x != y At least for our purposes (realtime control laws), we generally don't care how numerical errors affect the following comparisons: x < y x <= y x >= y x > y This is what the gcc warning -Wfloat-equal checks for. In our environment, we can compile with gcc, so we just turn off the splint -real-compare flag. However, it seems like splint should refine its notion of real-compare if its going to bother with that type of check. -Jay From khindenburg at cherrynebula.net Thu Oct 9 02:47:56 2003 From: khindenburg at cherrynebula.net (Kurt V. Hindenburg) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Fresh storage allocated/free Message-ID: <200310090148.02066.khindenburg@cherrynebula.net> After reading the manual I'm not entirely sure how to remove this warning/error. splint recognizes the new but not the free. I have the following code : GString *mboxes = g_string_sized_new(512); /* 844 */ [...] g_string_free(mboxes, TRUE); } /* 931 */ Between the statements there is no way to exit the routine. splint gives an error on this: gkrellsun.c: (in function update_tooltip) gkrellsun.c:931:2: Fresh storage mboxes not released before return A memory leak has been detected. Storage allocated locally is not released before the last reference to it is lost. (Use -mustfreefresh to inhibit warning) gkrellsun.c:844:4: Fresh storage mboxes allocated -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20031009/6f1b5faf/attachment.bin From evans at cs.virginia.edu Thu Oct 9 09:23:14 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Fresh storage allocated/free In-Reply-To: <200310090148.02066.khindenburg@cherrynebula.net> References: <200310090148.02066.khindenburg@cherrynebula.net> Message-ID: You need to annotate your g_string_free method to document that it takes ownership of the storage. Something like this, void g_string_free (/*@only@*/ GString *, bool); --- Dave On Thu, 9 Oct 2003, Kurt V. Hindenburg wrote: > After reading the manual I'm not entirely sure how to remove this > warning/error. splint recognizes the new but not the free. I have > the following code : > > GString *mboxes = g_string_sized_new(512); /* 844 */ > [...] > g_string_free(mboxes, TRUE); > } /* 931 */ > Between the statements there is no way to exit the routine. > > splint gives an error on this: > gkrellsun.c: (in function update_tooltip) > gkrellsun.c:931:2: Fresh storage mboxes not released before return > A memory leak has been detected. Storage allocated locally is not > released > before the last reference to it is lost. (Use -mustfreefresh to > inhibit > warning) > gkrellsun.c:844:4: Fresh storage mboxes allocated > From khindenburg at cherrynebula.net Thu Oct 9 12:54:45 2003 From: khindenburg at cherrynebula.net (Kurt V. Hindenburg) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Fresh storage allocated/free In-Reply-To: References: <200310090148.02066.khindenburg@cherrynebula.net> Message-ID: <200310091154.45512.khindenburg@cherrynebula.net> On Thursday 09 October 2003 08:23 am, David Evans wrote: | You need to annotate your g_string_free method to document that it | takes ownership of the storage. Something like this, | | void g_string_free (/*@only@*/ GString *, bool); OK, thanks. At least I have an idea what's going on. The problem is I really don't want to start modifying GTK's headers system-wide. If I add extern gchar* g_string_free (/*@only@*/ GString *, gboolean); to gkrellsun.c I then get gkrellsun.c:20:41: Parameter inconsistently redeclared as only storage, previously declared as implicitly temp storage A function, variable or constant is redefined with a different type. (Use -incondefs to inhibit warning) usr/include/glib-2.0/glib/gstring.h:61:46: Declaration of string Perhaps this is better than memory errors... Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20031009/4dc6c30a/attachment.bin From nayan22 at bolt.com Sat Oct 11 23:18:09 2003 From: nayan22 at bolt.com (Nayan ) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Parse error: Non-function declaration Message-ID: <20031012031809.10878.qmail@bolt.com> Hi, I have come across different type of parse error this time. When I run splint I get following error: Splint 3.1.1 --- 26 Sep 2003 /usr/include/glib-2.0/glib/gtypes.h:43:8: Parse Error: Non-function declaration: G_BEGIN_DECLS : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. G_BEGIN_DECLS is a macro used along with G_END_DECLS. Only official documentation that I could find about it is at http://developer.gnome.org/doc/API/2.0/glib/glib-Miscellaneous-Macros.html The offending code in gtypes.h is like: G_BEGIN_DECLS // line 7 // bunch of typedefs // line 8 // lots of #defines // some #ifs G_END_DECLS // line 322 Any suggestions on how to fix this error. Thanks in advance, Nayan -- ______________________________________ Get your free email from www.bolt.com! Powered by Outblaze From khindenburg at cherrynebula.net Sat Oct 11 23:58:12 2003 From: khindenburg at cherrynebula.net (Kurt V. Hindenburg) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Parse error: Non-function declaration In-Reply-To: <20031012031809.10878.qmail@bolt.com> References: <20031012031809.10878.qmail@bolt.com> Message-ID: <200310112258.20333.khindenburg@cherrynebula.net> On Saturday 11 October 2003 10:18 pm, Nayan wrote: | Splint 3.1.1 --- 26 Sep 2003 | | /usr/include/glib-2.0/glib/gtypes.h:43:8: Parse Error: | Non-function declaration: G_BEGIN_DECLS : | int. (For help on parse errors, see splint -help parseerrors.) | *** Cannot continue. | Well, I'm using splint on a program that uses glib2/gtk2 and I don't get any parse errors. I'm using Splint 3.0.1.6. Maybe someone else has an idea. Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20031011/1599d9a9/attachment.bin From ok at cs.otago.ac.nz Sun Oct 12 21:31:32 2003 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Parse error: Non-function declaration Message-ID: <200310130131.h9D1VWes249090@atlas.otago.ac.nz> "Nayan " wrote: /usr/include/glib-2.0/glib/gtypes.h:43:8: Parse Error: Non-function declaration: G_BEGIN_DECLS : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. It looks as though you are not including the header where G_BEGIN_DECLS is #defined. For use with C, is supposed to #define G_BEGIN_DECLS and G_END_DECLS both as having empty replacements. From Marco.Giromini at marconiselenia.com Mon Oct 13 05:23:33 2003 From: Marco.Giromini at marconiselenia.com (Marco.Giromini@marconiselenia.com) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] real-compare Message-ID: I do agree with you. Particularly with the following: " it would be nice to catch and warn about the following comparisons: x == y x != y At least for our purposes (realtime control laws), we generally don't care how numerical errors affect the following comparisons: x < y x <= y x >= y x > y " I think this is in accordance with the rule below: Misra Rule 50: Floating point variables shall not be tested for exact equality or inequality. E.g.: static S32 test( F64 x, F64 y ) { S32 r = 0; if (x == y) /* MISRA Violation */ { r = 1; } if (x != y) /* MISRA Violation */ { r = -1; } "Jay A. St. Pierre" @cs.virginia.edu on 10/08/2003 10:07:25 PM Please respond to splint-discuss@cs.virginia.edu Sent by: splint-discuss-admin@cs.virginia.edu To: splint-discuss@cs.virginia.edu cc: Subject: [splint-discuss] real-compare I think that the real-compare check could be improved. For example, consider this piece of code: #include #include int main(void) { double x=1.0e-30; double y=2.0e-30; if (y>x) { printf("Case 1: y > x\n"); } if ( (y-x) > DBL_EPSILON ) { printf("Case 2: y > x\n"); } if ( (y-x) > x*DBL_EPSILON ) { printf("Case 3: y > x\n"); } return(0); } If I run splint on this, I get: Splint 3.1.1 --- 20 May 2003 foo.c: (in function main) foo.c:9:7: Dangerous comparison involving double types: y > x Two real (float, double, or long double) values are compared directly using a C primitive. This may produce unexpected results since floating point representations are inexact. Instead, compare the difference to FLT_EPSILON or DBL_EPSILON. (Use -realcompare to inhibit warning) foo.c:17:8: Dangerous comparison involving double types: (y - x) > x * DBL_EPSILON Finished checking --- 2 code warnings DBL_EPSILON, according to the C99 Standard is 1E-9 or smaller. Even assuming its 2E-16, comparing the difference of x and y above to DBL_EPSILON is useless in determining whether one or the other is greater (as can be seen if you try to compile and run the above program: Case 2 will not be true). Without manually reimplementing the comparison operator so that each step can satisfy splint (progressivly compare signs, exponents, mantissas), a programmer doing many floating point comparisons might as well turn off the real-compare splint flag. However it would be nice to catch and warn about the following comparisons: x == y x != y At least for our purposes (realtime control laws), we generally don't care how numerical errors affect the following comparisons: x < y x <= y x >= y x > y This is what the gcc warning -Wfloat-equal checks for. In our environment, we can compile with gcc, so we just turn off the splint -real-compare flag. However, it seems like splint should refine its notion of real-compare if its going to bother with that type of check. -Jay _______________________________________________ splint-discuss mailing list splint-discuss@cs.virginia.edu http://www.splint.org/mailman/listinfo/splint-discuss From nayan22 at bolt.com Mon Oct 13 05:24:10 2003 From: nayan22 at bolt.com (Nayan ) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Parse error: Non-function declaration Message-ID: <20031013092411.31236.qmail@bolt.com> I tried splint version 3.0.1.6 - it gives exactly the same error to me :( Nayan ----- Original Message ----- From: "Kurt V. Hindenburg" Date: Sat, 11 Oct 2003 22:58:12 -0500 To: splint-discuss@cs.virginia.edu, "Nayan " Subject: Re: [splint-discuss] Parse error: Non-function declaration > On Saturday 11 October 2003 10:18 pm, Nayan wrote: > | Splint 3.1.1 --- 26 Sep 2003 > | > | /usr/include/glib-2.0/glib/gtypes.h:43:8: Parse Error: > | Non-function declaration: G_BEGIN_DECLS : > | int. (For help on parse errors, see splint -help parseerrors.) > | *** Cannot continue. > | > Well, I'm using splint on a program that uses glib2/gtk2 and I don't > get any parse errors. I'm using Splint 3.0.1.6. Maybe someone else > has an idea. > Kurt -- ______________________________________ Get your free email from www.bolt.com! Powered by Outblaze From nayan22 at bolt.com Mon Oct 13 06:22:35 2003 From: nayan22 at bolt.com (Nayan ) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] Parse error: Non-function declaration Message-ID: <20031013102236.31831.qmail@bolt.com> ----- Original Message ----- From: "Richard A. O'Keefe" Date: Mon, 13 Oct 2003 14:31:32 +1300 (NZDT) To: splint-discuss@cs.virginia.edu Subject: Re: [splint-discuss] Parse error: Non-function declaration "Nayan " wrote: /usr/include/glib-2.0/glib/gtypes.h:43:8: Parse Error: Non-function declaration: G_BEGIN_DECLS : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. It looks as though you are not including the header where G_BEGIN_DECLS is #defined. For use with C, is supposed to #define G_BEGIN_DECLS and G_END_DECLS both as having empty replacements. _______________________________________ Hello Richard, Thanks for your input. This parse error was be related with definition of G_BEGIN_DECLS. The sequence in which glib's include directory's were specified was not correct. Therefore splint was not able to find the definitions. Got that fixed now. Nayan -- ______________________________________ Get your free email from www.bolt.com! Powered by Outblaze From knollj at cranepm10.com Sat Oct 18 22:14:53 2003 From: knollj at cranepm10.com (Knoll, Jim) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char Message-ID: <4E5746B225021E4CB006849829AFA2DD059D2F@INDY-X> Hello, The following code receives warnings that I would like to ignore. unsigned char i; i = 0; I know I could use +charint to ignore the warning, but it will not warn me on the following code. unsigned char i; i = 256; Is there a way to enable warnings when the assigned value exceeds the max value for the type being assigned to while ignoring warnings when the value is within the limits for the type being assigned to? Thanks, Jim From Marco.Giromini at marconiselenia.com Mon Oct 20 05:53:30 2003 From: Marco.Giromini at marconiselenia.com (Marco.Giromini@marconiselenia.com) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char Message-ID: I think that your problem is strictly related to the one reported below - unfortunately I didn't receive any conclusive unswer. I try to add something, that could partially solve your problem. If you change y=2 with y=0x02 you still receive the Splint warning: Assignment of int to unsigned char: y = 0x02 If you change y=2 with y='\x02' you should not receive any Splint warning. Anyway 256 is a special value: In an implementation in which type char has the same range of values as signed char, the integer character constant '\xFF' has the value -1; if type char has the same range of values as unsigned char, the character constant '\xFF' has the value +255. [ISO C99 page 61 point 13] Giromini ---------------------- Forwarded by Marco Giromini/MAIN/MC1 on 10/20/2003 11:27 AM --------------------------- Marco.Giromini@marconiselenia.com@cs.virginia.edu on 09/26/2003 12:39:51 PM Please respond to splint-discuss@cs.virginia.edu Sent by: splint-discuss-admin@cs.virginia.edu To: splint-discuss@cs.virginia.edu cc: Subject: Re: [splint-discuss] Very strict cast checking Some sort of compatibility rules should be useful for integer constants v.s. other predefined types. This is particularly true for the "char" predefined type. For other types the following suffix could be used (but not for legacy code): unsigned-suffix: one of u U long-suffix: one of l L long-long-suffix: one of ll LL For instance, in: int x; char y; y=x; /* flag this */ x=1; /* don't flag this */ y=2; /* don't flag this */ Anyway I get: Assignment of int to char: y=2 To make char and int types equivalent, use +charint But I don't want to use +charint, otherwise I would loose the warning for y=x; Could anyone help me please ? Marco Giromini ---------------------- Forwarded by Marco Giromini/MAIN/MC1 on 09/26/2003 12:04 PM --------------------------- Derek M Jones @cs.virginia.edu on 08/21/2003 08:50:42 PM Please respond to splint-discuss@cs.virginia.edu Sent by: splint-discuss-admin@cs.virginia.edu To: splint-discuss@cs.virginia.edu cc: Subject: Re: [splint-discuss] Very strict cast checking ... However, simply treating typedef names as distinct types is too simplistic. Some sort of compatibility rules have to be worked out for integer constants. For instance, in: typedef int MY_INT; int x; MY_INT y; x+y; /* flag this */ x+1; /* don't flag this */ y+1; /* don't flag this */ derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek@knosof.co.uk Applications Standards Conformance Testing http://www.knosof.co.uk "Knoll, Jim" @cs.virginia.edu on 10/19/2003 04:14:53 AM Please respond to splint-discuss@cs.virginia.edu Sent by: splint-discuss-admin@cs.virginia.edu To: "'splint-discuss@cs.virginia.edu'" cc: Subject: [splint-discuss] numeric constant assignment to unsigned char Hello, The following code receives warnings that I would like to ignore. unsigned char i; i = 0; I know I could use +charint to ignore the warning, but it will not warn me on the following code. unsigned char i; i = 256; Is there a way to enable warnings when the assigned value exceeds the max value for the type being assigned to while ignoring warnings when the value is within the limits for the type being assigned to? Thanks, Jim _______________________________________________ splint-discuss mailing list splint-discuss@cs.virginia.edu http://www.splint.org/mailman/listinfo/splint-discuss From cbfalconer at yahoo.com Mon Oct 20 07:24:04 2003 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char References: Message-ID: <3F93C5D4.49A30B9A@yahoo.com> **** top posting fixed **** Marco.Giromini@marconiselenia.com wrote: > "Knoll, Jim" wrote: > > ... snip ... > > > > For instance, in: > > int x; > > char y; > > y=x; /* flag this */ > > x=1; /* don't flag this */ > > y=2; /* don't flag this */ > > > > Anyway I get: > > Assignment of int to char: y=2 > > To make char and int types equivalent, use +charint > > > > But I don't want to use +charint, otherwise I would loose the > > warning for y=x; > > I think that your problem is strictly related to the one > reported below - unfortunately I didn't receive any conclusive > unswer. I try to add something, that could partially solve your > problem. > > If you change y=2 with y=0x02 you still receive the Splint > warning: > > Assignment of int to unsigned char: y = 0x02 > > If you change y=2 with y='\x02' you should not receive any > Splint warning. Anyway 256 is a special value: > > In an implementation in which type char has the same range of > values as signed char, the integer character constant '\xFF' > has the value -1; if type char has the same range of values > as unsigned char, the character constant '\xFF' has the value > +255. [ISO C99 page 61 point 13] This is section 6.4.4.4 (at least in N869), which is much more useful than "page 61". You actually mean 255 above, not 256, I hope. The point seems to be that the constant 2 is an integer, while '\0x02' is considered a character, and thus does not trigger the warning. I think all this requires is that the user write char constants (i.e. '') rather than integer constants. The result is much clearer to all. Meanwhile, splint will miss warning on the valid: char x = 'ab'; c:\c\junk>type junk.c int main(void) { char x, y = 'ab'; x = 2; x = '\2'; x = y; return 0; } c:\c\junk>splint junk.c Splint 3.0.1.6 --- 11 Feb 2002 junk.c: (in function main) junk.c(5,3): Assignment of int to char: x = 2 To make char and int types equivalent, use +charint. Finished checking --- 1 code warning c:\c\junk> Please do not toppost, nor delete attributions for quoted material. I fixed this, which was very confused. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From ob at duometric.de Mon Oct 20 10:17:05 2003 From: ob at duometric.de (Oliver Betz) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char In-Reply-To: <3F93C5D4.49A30B9A@yahoo.com> Message-ID: <3F940A81.20280.1CC4083@localhost> CBFalconer wrote: [Splint and literal constants] > > If you change y=2 with y='\x02' you should not receive any > > Splint warning. Anyway 256 is a special value: this is a clean but rather academic way - a char has to be a char and not a 8 bit integer. Ceterum senseo there is the embedded world (seemingly forgotten by C99), where 8 bit integers are widely used and IMNSHO it's annoying to use the workaround above. If I want to assign a computed value, e.g. y = BUSFRQ/120; // set counter to get 120kHz output it's not suitable. BTW: PC-Lint checks the actual value of the literal constant against the range of the variable, and catches also char x = 'ab' with two messages: a "Multiple character constant" info, and a "Loss of information" warning. Oliver P.S.: I don't receive money from Gimpel. -- Oliver Betz DUOmetric GmbH Buero Muenchen Stockdorfer Str. 54 D-81475 Muenchen Tel ++49-89-75967390 Fax ++49-89-75967391 From Simon.Hosie at connexionz.co.nz Mon Oct 20 18:51:28 2003 From: Simon.Hosie at connexionz.co.nz (Simon Hosie) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char Message-ID: Knoll, Jim: > The following code receives warnings that I would like to ignore. > unsigned char i; > i = 0; > [...] If a variable/type could have a value range associated with it then you could use typedefs to make tiny numeric types with /*@alt int@*/ and limit their range to protect yourself from unreasonable values. Then a char can go back to being special. -- Footer beyond this point was added without my consent, please disregard it. _______________________________________ Connexionz Ltd Simon Hosie Simon.Hosie@connexionz.co.nz __________________________________________________ New Zealand Office Building 2,Level 1,1 Show Place Christchurch Office: +64 33394536 Fax: +64 33394537 http://www.connexionz.co.nz United Kingdom Office Regus House, Fairbourne Drive, Atterbury -Milton Keyes MK10 9RG Phone : 02890 577 774 The information in this email (including attachments) is confidential and may be legally privileged. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email and destroy the message. If you are not the intended recipient, any use, disclosure, copying or distribution is prohibited and may be unlawful From silvia_giro at everyday.com Mon Oct 20 16:20:34 2003 From: silvia_giro at everyday.com (SILVIA_GIRO) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char Message-ID: <5.0.2.1.2.20031020215023.009f4700@virtual.everyday.com> I apologise for the toppost. I was in a hurry so I simply replyed (instead of responding to splint-discuss) and I made confusion (e.g. 256 !). Please let me clarify what I wanted to point out. For legacy code in general, and for embedded code in particular, it should be useful to distinguish between: * implicit cast from integer to char (e.g. y=x) * implicit cast from integer constant to char (e.g. y=2) As far as I know, the only solution with Splint is to keep -charint, adding the academic advice "write char rather than integer constants". So my implicit suggestion was to split -charint in two different flags (but I thought I've missed something). Marco Giromini P.S. I'm writing from home. If you need if from my original address I'll do it the day after tomorrow. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20031020/fa887723/attachment.htm From Jay.St.Pierre at Colorado.EDU Tue Oct 21 00:37:39 2003 From: Jay.St.Pierre at Colorado.EDU (Jay A. St. Pierre) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] bug with -load flag Message-ID: I have the following piece of code: #include #include #include int main(void) { printf("Hello World\n"); return 0; } When I run splint with no arguments, I get: $ splint foo.c Splint 3.1.1 --- 20 May 2003 Finished checking --- no warnings Now, when I run it using the -load flag to tell it to load the standard.lcd file that comes with splint, I get: $ splint +load /opt/splint-3.1.1/share/splint/lib/standard.lcd foo.c Splint 3.1.1 --- 20 May 2003 foo.c:3:21: Cannot find include file stdbool.h on search path: /usr/include;/opt/splint-3.1.1/include Preprocessing error. (Use -preproc to inhibit warning) Preprocessing error for file: /tmp/foo.c *** Cannot continue. So, I add in the include path for the compiler's header files. In this case, they are the gcc (3.2.3) header files. I've copied them to /tmp/gcc-include to keep the pathnames short. I also included the switch to skip the iso headers (which should not matter): $ splint -I/tmp/gcc-include \ +load /opt/splint-3.1.1/share/splint/lib/standard.lcd \ +skip-iso-headers foo.c Splint 3.1.1 --- 20 May 2003 Command Line: Setting +skipisoheaders redundant with current value gcc-include/stdarg.h:43:41: No type before declaration name (implicit int type): __builtin_va_list : int A variable declaration has no explicit type. The type is implicitly int. (Use -imptype to inhibit warning) gcc-include/stdarg.h:43:41: Parse Error: Suspect missing struct or union keyword: __builtin_va_list : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. OK, this is not unexpected, since I have not identified /tmp/gcc-include as a "system" include directory. I'll do so now (keeping the +skip-iso-headers just for fun): $ splint -I/tmp/gcc-include \ +sysdirs /tmp/gcc-include \ +load /opt/splint-3.1.1/share/splint/lib/standard.lcd \ +skip-iso-headers foo.c Splint 3.1.1 --- 20 May 2003 Command Line: Setting +skipisoheaders redundant with current value gcc-include/stdarg.h:43:41: Parse Error: Suspect missing struct or union keyword: __builtin_va_list : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. Why is it parsing stdarg.h? If I specify the standard.lcd in another way: $ splint -I/tmp/gcc-include \ +sysdirs /tmp/gcc-include \ +standard \ +skip-iso-headers foo.c Splint 3.1.1 --- 20 May 2003 Command Line: Setting +skipisoheaders redundant with current value Finished checking --- no warnings it works! Now the problem is that we need to add POSIX Realtime Extensions to the splint library file that we are using (i.e., we need to use the -load flag). The above behavior is preventing us from running splint on certain files. I believe it is a bug, but if not, please enlighten me and point me to a workaround. Thanks. -Jay From evans at cs.virginia.edu Tue Oct 21 01:38:03 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:17 2006 Subject: [splint-discuss] bug with -load flag In-Reply-To: References: Message-ID: On Mon, 20 Oct 2003, Jay A. St. Pierre wrote: > I have the following piece of code: > > #include > #include > #include > ... > > When I run splint with no arguments, I get: > > $ splint foo.c > Splint 3.1.1 --- 20 May 2003 > > Finished checking --- no warnings > > Now, when I run it using the -load flag to tell it to load the > standard.lcd file that comes with splint, I get: > > $ splint +load /opt/splint-3.1.1/share/splint/lib/standard.lcd foo.c > Splint 3.1.1 --- 20 May 2003 > > foo.c:3:21: Cannot find include file stdbool.h on search path: > /usr/include;/opt/splint-3.1.1/include > Preprocessing error. (Use -preproc to inhibit warning) > Preprocessing error for file: /tmp/foo.c > *** Cannot continue. > Splint only skips the ANSI standard headers if the library is used. In this case, it doesn't know that the +load .../standard.lcd is the standard library, so it doesn't skip the standard headers. Note that when you generate a library running splint on your code with the standard library, the generated library includes this information that it was produced using the standard library (or unix, posix library as the case may be) and will skip the appropriate headers. So, I'm not sure I understand why you are running into this problem when you generate your libraries with the POSIX real time extendions. The standard.lcd doesn't include that information (since it wasn't generated from a splint run that used the standard library), but it probably should so the behavior is the same whether you load it explicitly or normally. --- Dave From Marco.Giromini at marconiselenia.com Tue Oct 21 10:17:27 2003 From: Marco.Giromini at marconiselenia.com (Marco.Giromini@marconiselenia.com) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] numeric constant assignment to unsigned char Message-ID: Here is it ! ---------------------- Forwarded by Marco Giromini/MAIN/MC1 on 10/21/2003 04:15 PM --------------------------- SILVIA_GIRO @cs.virginia.edu on 10/20/2003 10:20:34 PM Please respond to splint-discuss@cs.virginia.edu Sent by: splint-discuss-admin@cs.virginia.edu To: splint-discuss@cs.virginia.edu cc: Marco.Giromini@marconiselenia.com Subject: Re: Re: [splint-discuss] numeric constant assignment to unsigned char I apologise for the toppost. I was in a hurry so I simply replyed (instead of responding to splint-discuss) and I made confusion (e.g. 256 !). Please let me clarify what I wanted to point out. For legacy code in general, and for embedded code in particular, it should be useful to distinguish between: implicit cast from integer to char (e.g. y=x) implicit cast from integer constant to char (e.g. y=2) As far as I know, the only solution with Splint is to keep -charint, adding the academic advice "write char rather than integer constants". So my implicit suggestion was to split -charint in two different flags (but I thought I've missed something). Marco Giromini P.S. I'm writing from home. If you need if from my original address I'll do it the day after tomorrow. From Jay.St.Pierre at Colorado.EDU Tue Oct 21 12:13:06 2003 From: Jay.St.Pierre at Colorado.EDU (Jay A. St. Pierre) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] bug with -load flag In-Reply-To: Message-ID: On Tue, 21 Oct 2003, David Evans wrote: > On Mon, 20 Oct 2003, Jay A. St. Pierre wrote: > > > I have the following piece of code: > > > > #include > > #include > > #include > > ... > > > > When I run splint with no arguments, I get: > > > > $ splint foo.c > > Splint 3.1.1 --- 20 May 2003 > > > > Finished checking --- no warnings > > > > Now, when I run it using the -load flag to tell it to load the > > standard.lcd file that comes with splint, I get: > > > > $ splint +load /opt/splint-3.1.1/share/splint/lib/standard.lcd foo.c > > Splint 3.1.1 --- 20 May 2003 > > > > foo.c:3:21: Cannot find include file stdbool.h on search path: > > /usr/include;/opt/splint-3.1.1/include > > Preprocessing error. (Use -preproc to inhibit warning) > > Preprocessing error for file: /tmp/foo.c > > *** Cannot continue. > > > > Splint only skips the ANSI standard headers if the library is used. In > this case, it doesn't know that the +load .../standard.lcd is the standard > library, so it doesn't skip the standard headers. But shouldn't it skip the standard headers if I include the +skip-iso-headers (or +skip-ansi-headers) flag? This does not seem to work: $ splint +load /opt/splint-3.1.1/share/splint/lib/standard.lcd \ +skip-iso-headers foo.c Command Line: Setting +skipisoheaders redundant with current value foo.c:3:21: Cannot find include file stdbool.h on search path: /usr/include;/opt/splint-3.1.1/include Preprocessing error. (Use -preproc to inhibit warning) Preprocessing error for file: /tmp/foo.c *** Cannot continue. > Note that when you generate a library running splint on your > code with the standard library, the generated library includes > this information that it was produced using the standard > library (or unix, posix library as the case may be) and will > skip the appropriate headers. So, I'm not sure I understand > why you are running into this problem when you generate your > libraries with the POSIX real time extendions. The > standard.lcd doesn't include that information (since it wasn't > generated from a splint run that used the standard library), > but it probably should so the behavior is the same whether you > load it explicitly or normally. Referring to the above example, if its not skipping the iso headers because I'm explicitly loading standard.lcd, why does it complain "+skipisoheaders redundant with current value" when I use the +skip-iso-headers flag? Am I not understanding the +skip-iso-headers flag correctly? As a further note, the library we are creating is just a small superset of the posix.lcd that comes with splint. We create a posix-rte.h that has annotated POSIX.4 structures, constants, and prototypes, then we run the command: splint -nolib standard.h posix.h posix-rte.h -dump posix-rte Then we use this library to check our code. Using the +skip-posix-headers flag with this library generates the "redundant" complaint, and by and large seems to work fine. So far its just code that is including gcc-3.2.3's stdarg.h that exhibits this problem. Thanks for your time. -Jay From dwh at ovro.caltech.edu Tue Oct 28 18:13:29 2003 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Help with mmap() and abstract data type annotations Message-ID: Hi all, First, thanks for the excellent tool! Splint is great. I'm writing an API for controlling custom hardware. In the spirit of 'abstraction', the user of this library will know nothing about the underlying hardware, and all API functions will contain a 'slot' parameter in their argument lists. The library then uses this 'slot' as an index into a data structure containing all the info on the underlying hardware, eg. file handle, memory mapped base address, etc. I've run into some trouble with getting splint to be happy with mmap(). The solution to this is perhaps to use an extra command line switch. The command line I have been using is splint -warnposix .c since that was the flag recommended by splint when it produced warnings about the use of the Linux headers. Another tricky thing I have found is when passing around the board's base address in the underlying library. The library functions can 'see' the statically allocated array of abstract data types, so instead of defining another function layer (getBase(slot)), the API implementation uses device_array[slot]->base directly. I've tried to come up with a simple test case that if I can get annotated to work correctly, I think I can get this API annotated correctly. So, could some kind soul please take a look at this simple test code below and see if they can a) Get splint to stop complaining about mmap() b) Get the abstract data type based code to go through without errors. Many thanks! Regards, Dave Hawkins Owens Valley Radio Observatory, Caltech. /** * \file splintTest2.c * \brief Splint test. * * What annotations make mmap work? * * What annotations get rid of the warnings related * to the global file_handle[] array? * *
* $Author: $ * $Date: $ * $Revision: $ *
*/ #include #include #include #include #include #include enum {MEM_SIZE = 0x400}; /* 1kB */ /* Memory map a file, and return a pointer */ /*@null@*/ /*@only@*/ static int *openPointer(char *filename); static void closePointer(/*@only@*/ int *base); /* Memory map a file, and return a handle */ static int openHandle(char *filename); static void closeHandle(int handle); /*@null@*/ /*@temp@*/ static int *getBase(int handle); enum {MAX_HANDLE = 4}; typedef /*@abstract@*/ int *FILE_HANDLE ; static FILE_HANDLE file_handle[MAX_HANDLE]; /* Test routines */ static void testPointer(); static void testHandle(); int main() { testPointer(); testHandle(); return 0; } /* No splint warnings for this code * (so long as 'only' is used in the open/close functions) */ static void testPointer(void) { int *base; int i; /* Open and memory map a file */ base = openPointer("test1"); if (base == NULL) { printf("NULL oops!\n"); return; } printf("The base address is %X\n", (unsigned int)base); for (i = 0; i < 10; i++) { base[i] = i; } for (i = 0; i < 10; i++) { printf("%X\n", (unsigned int)base[i]); } closePointer(base); } static void testHandle(void) { int *base; int handle; int i; /* Now do it the handle way */ handle = openHandle("test2"); if (handle < 0) { printf("handle < 0 oops!\n"); return; } printf("handle = %d\n", handle); base = getBase(handle); if (base == NULL) { printf("NULL oops!\n"); return; } printf("The base address is %X\n", (unsigned int)base); for (i = 0; i < 10; i++) { base[i] = i; } for (i = 0; i < 10; i++) { printf("%X\n", (unsigned int)base[i]); } closeHandle(handle); } static int *openPointer(char *filename) { int fd; int *base = NULL; char tmp[] = "X"; if (filename == NULL) { return NULL; } /* Create something we can mmap */ fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, S_IRWXU); if (fd < 0) { return NULL; } (void)lseek(fd, MEM_SIZE-1, SEEK_SET); (void)write(fd, tmp, 1); /* Mmap with (PROT_READ|PROT_WRITE) to match open() flags */ base = (int *)mmap( NULL, (size_t)MEM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); if(base == (int *)MAP_FAILED) { (void)close(fd); return NULL; } (void)close(fd); return base; } static void closePointer(int *base) { if (base != NULL) { (void)munmap((caddr_t)base,(size_t)MEM_SIZE); } } static int openHandle(char *filename) { int *base; int i = 0; /* Find an unused handle */ while ((file_handle[i] != NULL) && (i < MAX_HANDLE)) { i++; } if (i == MAX_HANDLE) { return -1; } base = openPointer(filename); if (base == NULL) { return -1; } file_handle[i] = base; return i; } static void closeHandle(int handle) { if ((handle < 0) || (handle >= MAX_HANDLE) || (file_handle[handle] == NULL)) { return; } closePointer(file_handle[handle]); file_handle[handle] = NULL; } static int *getBase(int handle) { if ((handle >= 0) && (handle < MAX_HANDLE)) { return file_handle[handle]; } else { return NULL; } } From dwh at ovro.caltech.edu Tue Oct 28 19:10:17 2003 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] mmap()-specific example In-Reply-To: Message-ID: I split the mmap() code apart from the previous test so that only the errors relevant to the mmap() question can be seen. splintTest2.c: (in function openPointer) splintTest2.c:82:5: Null storage passed as non-null param: mmap (NULL, ...) 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) splintTest2.c:90:15: Fresh storage base not released before return A memory leak has been detected. Storage allocated locally is not released before the last reference to it is lost. (Use -mustfreefresh to inhibit warning) splintTest2.c:81:2: Fresh storage base created splintTest2.c: (in function closePointer) splintTest2.c:101:2: Only storage base not released before return A memory leak has been detected. Only-qualified storage is not released before the last reference to it is lost. (Use -mustfreeonly to inhibit warning) splintTest2.c:96:31: Storage base becomes only Now, putting /*@-nullpass@*/ and /*@=nullpass@*/ around the arguments to the mmap() call can get rid of the null storage warning. But is this the correct way to remove these errors? I believe an alternate way is to generate an mmap() specification that has /*@null@*/ annotating that parameter. But I'm not sure how to proceed regarding the generation of such an annotated file. The other errors remain. I suspect that some annotations on munmap() that are similar to those on free() will remove those errors. So again, the generation of a specification file seems like it would be appropriate. Looking forward to some discussion :) Dave /** * \file splintTest2.c * \brief Splint test. * * A splint test using memory mapped file. * * What annotations make mmap work? * *
* $Author: $ * $Date: $ * $Revision: $ *
*/ #include #include #include #include #include #include enum {MEM_SIZE = 0x400}; /* 1kB */ /* Memory map a file, and return a pointer */ /*@null@*/ /*@only@*/ static int *openPointer(char *filename); static void closePointer(/*@only@*/ int *base); /* Test routines */ static void testPointer(); int main() { testPointer(); return 0; } /* No splint warnings for this code * (so long as 'only' is used in the open/close functions) */ static void testPointer(void) { int *base; int i; /* Open and memory map a file */ base = openPointer("test1"); if (base == NULL) { printf("NULL oops!\n"); return; } printf("The base address is %X\n", (unsigned int)base); for (i = 0; i < 10; i++) { base[i] = i; } for (i = 0; i < 10; i++) { printf("%X\n", (unsigned int)base[i]); } closePointer(base); } static int *openPointer(char *filename) { int fd; int *base = NULL; char tmp[] = "X"; if (filename == NULL) { return NULL; } /* Create something we can mmap */ fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, S_IRWXU); if (fd < 0) { return NULL; } (void)lseek(fd, MEM_SIZE-1, SEEK_SET); (void)write(fd, tmp, 1); /* Mmap with (PROT_READ|PROT_WRITE) to match open() flags */ base = (int *)mmap( NULL, (size_t)MEM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); if(base == (int *)MAP_FAILED) { (void)close(fd); return NULL; } (void)close(fd); return base; } static void closePointer(int *base) { if (base != NULL) { (void)munmap((caddr_t)base,(size_t)MEM_SIZE); } } From dwh at ovro.caltech.edu Tue Oct 28 19:26:14 2003 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Help with abstract data type annotations In-Reply-To: Message-ID: In the earlier abstract data type code I posted, I had simply use an int * as the abstract data type. The code below is a little more appropriate in that the abstract data type is a structure containing a couple of items. The splint warnings produced are: snip ... 3 mmap warnings and the abstract data type warnings: splintTest3.c:128:11: Storage file_handle[] reachable from global is owned (should be unqualified) Storage derivable from a parameter does not match the alias kind expected for the formal parameter. (Use -compmempass to inhibit warning) splintTest3.c:125:2: Storage file_handle[] becomes owned splintTest3.c: (in function closeHandle) splintTest3.c:138:7: Only storage file_handle[]->base (type int *) derived from released storage is not released (memory leak): file_handle[handle] A storage leak due to incomplete deallocation of a structure or deep pointer is suspected. Unshared storage that is reachable from a reference that is being deallocated has not yet been deallocated. Splint assumes when an object is passed as an out only void pointer that the outer object will be deallocated, but the inner objects will not. (Use -compdestroy to inhibit warning) splintTest3.c:138:7: Unqualified storage file_handle[handle] passed as only param: free (file_handle[handle]) Unqualified storage is transferred in an inconsistent way. (Use -unqualifiedtrans to inhibit warning) splintTest3.c: (in function getBase) splintTest3.c:145:10: Only storage file_handle[]->base returned as temp: file_handle[handle]->base The only reference to this storage is transferred to another reference (e.g., by returning it) that does not have the only annotation. This may lead to a memory leak, since the new reference is not necessarily released. (Use -onlytrans to inhibit warning) So, if anyone can help clarify the appropriate annotations, I'd sure appreciate it. Cheers, Dave /** * \file splintTest3.c * \brief Splint test. * * A splint test using an abstract data type. * * What annotations make mmap work? * * What annotations get rid of the warnings related * to the global file_handle[] array? * *
* $Author: $ * $Date: $ * $Revision: $ *
*/ #include #include #include #include #include #include enum {MEM_SIZE = 0x400}; /* 1kB */ enum {MAX_HANDLE = 4}; /* Memory map a file, and return a handle */ static int openHandle(char *filename); static void closeHandle(int handle); /*@null@*/ /*@temp@*/ static int *getBase(int handle); typedef /*@abstract@*/ /*@null@*/ struct FILE_INFO *FILE_HANDLE; struct FILE_INFO { int fd; /* Annotate this as only, since this is the pointer * used in releasing this 'resource' */ /*@only@*/ int *base; }; /* Array of pointers */ static FILE_HANDLE file_handle[MAX_HANDLE]; /* Test routines */ static void testHandle(); int main() { testHandle(); return 0; } static void testHandle(void) { int *base; int handle; int i; /* Now do it the handle way */ handle = openHandle("test2"); if (handle < 0) { printf("handle < 0 oops!\n"); return; } printf("handle = %d\n", handle); base = getBase(handle); if (base == NULL) { printf("NULL oops!\n"); return; } printf("The base address is %X\n", (unsigned int)base); for (i = 0; i < 10; i++) { base[i] = i; } for (i = 0; i < 10; i++) { printf("%X\n", (unsigned int)base[i]); } closeHandle(handle); } static int openHandle(char *filename) { int fd; int *base = NULL; char tmp[] = "X"; int i = 0; FILE_HANDLE fh; /* Find an unused handle */ while ((file_handle[i] != NULL) && (i < MAX_HANDLE)) { i++; } if (i == MAX_HANDLE) { return -1; } if (filename == NULL) { return -1; } /* Create something we can mmap */ fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, S_IRWXU); if (fd < 0) { return -1; } (void)lseek(fd, MEM_SIZE-1, SEEK_SET); (void)write(fd, tmp, 1); /* Mmap with (PROT_READ|PROT_WRITE) to match open() flags */ base = (int *)mmap( NULL, (size_t)MEM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); if(base == (int *)MAP_FAILED) { (void)close(fd); return -1; } fh = (FILE_HANDLE)malloc(sizeof(struct FILE_INFO)); if (fh == NULL) { return -1; } file_handle[i] = fh; file_handle[i]->fd = fd; file_handle[i]->base = base; return i; } static void closeHandle(int handle) { if ((handle < 0) || (handle >= MAX_HANDLE) || (file_handle[handle] == NULL)) { return; } (void)munmap((caddr_t)file_handle[handle]->base,(size_t)MEM_SIZE); (void)close(file_handle[handle]->fd); free(file_handle[handle]); file_handle[handle] = NULL; } static int *getBase(int handle) { if ((handle >= 0) && (handle < MAX_HANDLE) && (file_handle[handle] != NULL)) { return file_handle[handle]->base; } else { return NULL; } } From evans at cs.virginia.edu Tue Oct 28 19:33:53 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Help with mmap() and abstract data type annotations In-Reply-To: References: Message-ID: > I've run into some trouble with getting > splint to be happy with mmap(). The solution > to this is perhaps to use an extra command > line switch. > > The command line I have been using is > > splint -warnposix .c > I think the hint message you saw without -warnposix was misleading: mmap.c:15: Include file matches the name of a POSIX library, but the POSIX library is not being used. Consider using +posixlib or +posixstrictlib to select the POSIX library, or -warnposix to suppress this message. What this is really trying to suggest is that you probably want the +posixlib flag to select the POSIX library, or in the case actually want the +unixlib flag to select the Unix library. For the file_handle declaration, I suspect you want to allow NULL to be used as a FILE_HANDLE. Adding a /*@null@*/ annotation to the declaration, typedef /*@only@*/ /*@null@*/ /*@abstract@*/ int *FILE_HANDLE ; static FILE_HANDLE file_handle[MAX_HANDLE]; would document this (and eliminate the warnings about possibly null values in the file_handle array). I also added the /*@only@*/ annotation to indicate that the references in the file_handle array are the only references to that object. > Another tricky thing I have found is when > passing around the board's base address > in the underlying library. The library > functions can 'see' the statically allocated > array of abstract data types, so instead > of defining another function layer > (getBase(slot)), the API implementation > uses device_array[slot]->base directly. > I don't understand what the issue is here. You can use /*@access @*/ to provide access to an abstract datatype's implementation if that is what you want. > I've tried to come up with a simple test case > that if I can get annotated to work correctly, > I think I can get this API annotated > correctly. > > So, could some kind soul please take a look > at this simple test code below and see if > they can > > a) Get splint to stop complaining about mmap() > > b) Get the abstract data type based code to > go through without errors. > The other two changes I made are: o Added an /*@exposed@*/ annotation to getBase static /*@null@*/ /*@exposed@*/ int *getBase(int handle) since it is returning a reference to an object in the file_handle array. o Added a cast to (off_t) for the parameter to lseek: (void)lseek(fd, (off_t) (MEM_SIZE-1), SEEK_SET); (there are better ways of dealing with this). After those changes, splint +unixlib splintTest2.c produces no warnings. --- Dave From dwh at ovro.caltech.edu Tue Oct 28 19:51:25 2003 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Help with mmap() and abstract data type annotations In-Reply-To: Message-ID: Hi David, Excellent thanks. I'll make similar changes to the other test code, and read-up on what the annotations you've used mean. Reading the splint manual I got the impression that several types of annotations might be appropriate, but decided to approach the discussion group to get a solid answer. I've been adding casts to function calls where appropriate to remove splint warnings. Since I plan to run splint on code as I write and test blocks of it, I'm quite happy with this slight typing overhead. If you recommend an alternate approach, I'm happy to listen. I'll see if these changes fix my API code, and come back with any other questions. Thanks. Dave -----Original Message----- From: splint-discuss-admin@cs.virginia.edu [mailto:splint-discuss-admin@cs.virginia.edu]On Behalf Of David Evans Sent: Tuesday, October 28, 2003 4:34 PM To: splint-discuss@cs.virginia.edu Subject: Re: [splint-discuss] Help with mmap() and abstract data type annotations > I've run into some trouble with getting > splint to be happy with mmap(). The solution > to this is perhaps to use an extra command > line switch. > > The command line I have been using is > > splint -warnposix .c > I think the hint message you saw without -warnposix was misleading: mmap.c:15: Include file matches the name of a POSIX library, but the POSIX library is not being used. Consider using +posixlib or +posixstrictlib to select the POSIX library, or -warnposix to suppress this message. What this is really trying to suggest is that you probably want the +posixlib flag to select the POSIX library, or in the case actually want the +unixlib flag to select the Unix library. For the file_handle declaration, I suspect you want to allow NULL to be used as a FILE_HANDLE. Adding a /*@null@*/ annotation to the declaration, typedef /*@only@*/ /*@null@*/ /*@abstract@*/ int *FILE_HANDLE ; static FILE_HANDLE file_handle[MAX_HANDLE]; would document this (and eliminate the warnings about possibly null values in the file_handle array). I also added the /*@only@*/ annotation to indicate that the references in the file_handle array are the only references to that object. > Another tricky thing I have found is when > passing around the board's base address > in the underlying library. The library > functions can 'see' the statically allocated > array of abstract data types, so instead > of defining another function layer > (getBase(slot)), the API implementation > uses device_array[slot]->base directly. > I don't understand what the issue is here. You can use /*@access @*/ to provide access to an abstract datatype's implementation if that is what you want. > I've tried to come up with a simple test case > that if I can get annotated to work correctly, > I think I can get this API annotated > correctly. > > So, could some kind soul please take a look > at this simple test code below and see if > they can > > a) Get splint to stop complaining about mmap() > > b) Get the abstract data type based code to > go through without errors. > The other two changes I made are: o Added an /*@exposed@*/ annotation to getBase static /*@null@*/ /*@exposed@*/ int *getBase(int handle) since it is returning a reference to an object in the file_handle array. o Added a cast to (off_t) for the parameter to lseek: (void)lseek(fd, (off_t) (MEM_SIZE-1), SEEK_SET); (there are better ways of dealing with this). After those changes, splint +unixlib splintTest2.c produces no warnings. --- Dave _______________________________________________ splint-discuss mailing list splint-discuss@cs.virginia.edu http://www.splint.org/mailman/listinfo/splint-discuss From dwh at ovro.caltech.edu Wed Oct 29 13:24:20 2003 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Abstract data type annotation help In-Reply-To: Message-ID: Hi, Thanks Dave for the annotation suggestions yesterday. I've reposted the splintTest3.c code. Checking this code using splint +unixlib splintTest3.c Gives this one last error: splintTest3.c: (in function openHandle) splintTest3.c:128:11: Function returns with null storage derivable from global file_handle[]->base A possibly null pointer is reachable from a parameter or global variable that is not declared using a /*@null@*/ annotation. (Use -nullstate to inhibit warning) splintTest3.c:127:25: Storage file_handle[]->base becomes null Now, its possible that splint is confused due to the use of mmap here. The code checks for a valid return value from mmap, so there is no way that base will be null when assigning to file_handle[]->base. If this is a spurious warning, then I guess I could always add an if (base == NULL) test. Suggestions? There were several other errors due to the use of the local variable FILE_HANDLE fh in openHandle(). I added the annotation /*@temp@*/ - is that the correct annotation? My thinking for using it was that fh is a temporary variable, and that ownership was being passed to the global array. However, I thought that the annotation of only in the FILE_HANDLE type definition would have implied that the local FILE_HANDLE variable fh was passing ownership over to the global, and hence no annotation would be necessary. Care to comment/explain whats going on here? Thanks! Dave /** * \file splintTest3.c * \brief Splint test. * * A splint test using an abstract data type. * *
* $Author: $ * $Date: $ * $Revision: $ *
*/ #include #include #include #include #include #include enum {MEM_SIZE = 0x400}; /* 1kB */ enum {MAX_HANDLE = 4}; /* Memory map a file, and return a handle */ static int openHandle(char *filename); static void closeHandle(int handle); static /*@null@*/ /*@exposed@*/ int *getBase(int handle); typedef /*@only@*/ /*@null@*/ /*@abstract@*/ struct FILE_INFO *FILE_HANDLE; struct FILE_INFO { int fd; /* Annotate this as only, since this is the pointer * used in releasing this 'resource' */ /*@only@*/ int *base; }; /* Array of pointers */ static FILE_HANDLE file_handle[MAX_HANDLE]; /* Test routines */ static void testHandle(); int main() { testHandle(); return 0; } static void testHandle(void) { int *base; int handle; int i; /* Open the device */ handle = openHandle("test2"); if (handle < 0) { printf("handle < 0 oops!\n"); return; } printf("handle = %d\n", handle); base = getBase(handle); if (base == NULL) { printf("NULL oops!\n"); return; } printf("The base address is %X\n", (unsigned int)base); for (i = 0; i < 10; i++) { base[i] = i; } for (i = 0; i < 10; i++) { printf("%X\n", (unsigned int)base[i]); } closeHandle(handle); } static int openHandle(char *filename) { int fd; int *base = NULL; char tmp[] = "X"; int i = 0; /*@temp@*/ FILE_HANDLE fh; /* Find an unused handle */ while ((file_handle[i] != NULL) && (i < MAX_HANDLE)) { i++; } if (i == MAX_HANDLE) { return -1; } if (filename == NULL) { return -1; } /* Create something we can mmap */ fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, S_IRWXU); if (fd < 0) { return -1; } (void)lseek(fd, (off_t)(MEM_SIZE-1), SEEK_SET); (void)write(fd, tmp, 1); /* Mmap with (PROT_READ|PROT_WRITE) to match open() flags */ base = (int *)mmap( NULL, (size_t)MEM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); if(base == (int *)MAP_FAILED) { (void)close(fd); return -1; } fh = (FILE_HANDLE)malloc(sizeof(struct FILE_INFO)); if (fh == NULL) { return -1; } file_handle[i] = fh; file_handle[i]->fd = fd; file_handle[i]->base = base; return i; } static void closeHandle(int handle) { if ((handle < 0) || (handle >= MAX_HANDLE) || (file_handle[handle] == NULL) ) { return; } (void)munmap((caddr_t)file_handle[handle]->base,(size_t)MEM_SIZE); (void)close(file_handle[handle]->fd); free(file_handle[handle]); file_handle[handle] = NULL; } static int *getBase(int handle) { if ((handle >= 0) && (handle < MAX_HANDLE) && (file_handle[handle] != NULL)) { return file_handle[handle]->base; } else { return NULL; } } From terryc at tenberry.com Wed Oct 29 17:35:15 2003 From: terryc at tenberry.com (Terry Colligan) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Dealing with pointer functions that don't allocate Message-ID: <200310291535.15970.terryc@tenberry.com> A parsing idiom that I use a lot is to have a parsing function return a pointer to the next place in the buffer. When running splint on such a program, I get the following messages: isspam.c: (in function isspam) isspam.c:1961:17: Fresh storage p not released before return A memory leak has been detected. Storage allocated locally is not released before the last reference to it is lost. (Use -mustfreefresh to inhibit warning) isspam.c:1957:3: Fresh storage p created isspam.c:1962:3: Clauses exit with p referencing fresh storage in while body, local storage if loop is not taken The state of a variable is different depending on which branch is taken. This means no annotation can sensibly be applied to the storage. (Use -branchstate to inhibit warning) isspam.c:1957:3: Fresh storage p created Here is a reduced version of isspam: int isspam(char *buff) // buffer to check for spam { char *p = buff; // current point in buffer // parse each mail header while (*p != '\0' && *p != '\n') { p = parse_header(p); // this is line 1957 in above messages // check for no headers at all if ( xxxxxx ) return false; // this is line 1961 in above messages } The issue is that splint is treating 'parse_header' as a function which returns a pointer to new storage, when in reality, it is just returning a pointer to the same storage. This is pointer-as-a-sequence, rather than pointer-as-an-object. It seems I need to tell splint something about 'parse_header', but I can't figure out what. I've been reading the splint manual for a while, and looked on the mailing list archives for the last several months, but I can't figure out how to declare a function that takes a pointer arg, and returns a (possibly incremented) value for that pointer. Do I really have to disable these warnings? Or is there some way to tell splint what is going on? My .splintrc file: -D__volatile=volatile -warnposix -exitarg -predboolint -exportlocal -dependent-trans -boolops -compdef -temptrans -retvalint -nullassign -mustfreeonly -onlytrans -nullstate -globstate -nullpass -observertrans Any suggestions would be appreciated, even if it is only to say that it can't be done. -- Terry Terry Colligan mailto:terry-splint@tenberry.com Tenberry Software, Inc. http://www.tenberry.com info@tenberry.com phone 1.480.767.8868 fax 1.480.767.8709 From dwh at ovro.caltech.edu Wed Oct 29 18:00:57 2003 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Dealing with pointer functions that don't allocate In-Reply-To: <200310291535.15970.terryc@tenberry.com> Message-ID: I believe that if you annotate p as being temp, i.e., /*@temp@*/ char *p = buff; then you're telling splint that p is a temporary variable. I can't confirm that this is correct, but I believe it'll work. Dave -----Original Message----- From: splint-discuss-admin@cs.virginia.edu [mailto:splint-discuss-admin@cs.virginia.edu]On Behalf Of Terry Colligan Sent: Wednesday, October 29, 2003 2:35 PM To: splint-discuss@cs.virginia.edu Subject: [splint-discuss] Dealing with pointer functions that don't allocate A parsing idiom that I use a lot is to have a parsing function return a pointer to the next place in the buffer. When running splint on such a program, I get the following messages: isspam.c: (in function isspam) isspam.c:1961:17: Fresh storage p not released before return A memory leak has been detected. Storage allocated locally is not released before the last reference to it is lost. (Use -mustfreefresh to inhibit warning) isspam.c:1957:3: Fresh storage p created isspam.c:1962:3: Clauses exit with p referencing fresh storage in while body, local storage if loop is not taken The state of a variable is different depending on which branch is taken. This means no annotation can sensibly be applied to the storage. (Use -branchstate to inhibit warning) isspam.c:1957:3: Fresh storage p created Here is a reduced version of isspam: int isspam(char *buff) // buffer to check for spam { char *p = buff; // current point in buffer // parse each mail header while (*p != '\0' && *p != '\n') { p = parse_header(p); // this is line 1957 in above messages // check for no headers at all if ( xxxxxx ) return false; // this is line 1961 in above messages } The issue is that splint is treating 'parse_header' as a function which returns a pointer to new storage, when in reality, it is just returning a pointer to the same storage. This is pointer-as-a-sequence, rather than pointer-as-an-object. It seems I need to tell splint something about 'parse_header', but I can't figure out what. I've been reading the splint manual for a while, and looked on the mailing list archives for the last several months, but I can't figure out how to declare a function that takes a pointer arg, and returns a (possibly incremented) value for that pointer. Do I really have to disable these warnings? Or is there some way to tell splint what is going on? My .splintrc file: -D__volatile=volatile -warnposix -exitarg -predboolint -exportlocal -dependent-trans -boolops -compdef -temptrans -retvalint -nullassign -mustfreeonly -onlytrans -nullstate -globstate -nullpass -observertrans Any suggestions would be appreciated, even if it is only to say that it can't be done. -- Terry Terry Colligan mailto:terry-splint@tenberry.com Tenberry Software, Inc. http://www.tenberry.com info@tenberry.com phone 1.480.767.8868 fax 1.480.767.8709 _______________________________________________ splint-discuss mailing list splint-discuss@cs.virginia.edu http://www.splint.org/mailman/listinfo/splint-discuss From evans at cs.virginia.edu Wed Oct 29 18:32:52 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Dealing with pointer functions that don't allocate In-Reply-To: <200310291535.15970.terryc@tenberry.com> References: <200310291535.15970.terryc@tenberry.com> Message-ID: On Wed, 29 Oct 2003, Terry Colligan wrote: > > A parsing idiom that I use a lot is to have a parsing function > return a pointer to the next place in the buffer. When running > splint on such a program, I get the following messages: > > isspam.c: (in function isspam) > isspam.c:1961:17: Fresh storage p not released before return > A memory leak has been detected. Storage allocated locally is not released > before the last reference to it is lost. (Use -mustfreefresh to inhibit > warning) > isspam.c:1957:3: Fresh storage p created The annotation you want to use is /*@returned@*/. For example, char *parse_header (/*@returned@*/ char *p) means that the value returned by parse_header may be a reference to the parameter p. See http://www.splint.org/manual/html/sec6.html (6.1.2) for details. --- Dave From terry-splint at tenberry.com Wed Oct 29 22:19:13 2003 From: terry-splint at tenberry.com (Terry Colligan) Date: Wed Mar 22 17:10:18 2006 Subject: [splint-discuss] Dealing with pointer functions that don't allocate In-Reply-To: References: <200310291535.15970.terryc@tenberry.com> Message-ID: <200310292019.13193.terry-splint@tenberry.com> On Wednesday 29 October 2003 04:32 pm, David Evans wrote: > On Wed, 29 Oct 2003, Terry Colligan wrote: > > A parsing idiom that I use a lot is to have a parsing function > > return a pointer to the next place in the buffer. When running > > splint on such a program, I get the following messages: > > > > isspam.c: (in function isspam) > > isspam.c:1961:17: Fresh storage p not released before return > > A memory leak has been detected. Storage allocated locally is not > > released before the last reference to it is lost. (Use -mustfreefresh to > > inhibit warning) > > isspam.c:1957:3: Fresh storage p created > > The annotation you want to use is /*@returned@*/. For example, > > char *parse_header (/*@returned@*/ char *p) > > means that the value returned by parse_header may be a reference to the > parameter p. See http://www.splint.org/manual/html/sec6.html (6.1.2) for > details. > > --- Dave > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss Thanks! That worked. I seem to be having a little trouble finding things in the manual as I get started. I assume that it will get better as I learn to think about things in the 'splint way'... -- Terry Terry Colligan mailto:terry-splint@tenberry.com Tenberry Software, Inc. http://www.tenberry.com info@tenberry.com phone 1.480.767.8868 fax 1.480.767.8709