From vishal.bayskar at nechclst.in Tue Apr 1 08:12:45 2008 From: vishal.bayskar at nechclst.in (Vishal Bayskar) Date: Tue, 1 Apr 2008 21:42:45 +0530 Subject: [splint-discuss] warning -compmempass Message-ID: <0A8CFEC45B7F4C419F7543867C4744230157F49F@mailserver.nechclst.in> Dear All, Please help me in understanding the below warning file.c:1111:28: Storage servers[] reachable from global is fresh (should be unqualified) Storage derivable from a parameter does not match the alias kind expected for the formal parameter. (Use -compmempass to inhibit warning) What does this error meant? In code Memory is being allocated to the array servers[] in loop for ( i = 0 ;i <10;i++) { servers[i] = (char *) calloc (1,MAX_SERVERS); if servers[i]==NULL { Return 1; //this is a line number 1111 } } here servers[] is a global variable and declare as static char *servers[MAX_SERVERS]; Thanks and Regards Vishal Bayskar Ext. no. 927 Disclaimer: This message and any attachment(s) contained here are information that is confidential, proprietary to NEC HCL System Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. From ok at cs.otago.ac.nz Tue Apr 1 15:47:14 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 2 Apr 2008 12:47:14 +1300 Subject: [splint-discuss] Dependency on run time function In-Reply-To: <0A8CFEC45B7F4C419F7543867C47442301519AE8@mailserver.nechclst.in> References: <0A8CFEC45B7F4C419F7543867C47442301519AE8@mailserver.nechclst.in> Message-ID: <07EA0CCC-5CF9-4D90-861E-862438B48444@cs.otago.ac.nz> On 31 Mar 2008, at 5:39 pm, Vishal Bayskar wrote: > After read I have checked the len > And execution only go to the hdr.member if read was successful > Good. However, splint is an extended lint checker, not a program verifier. It's not "smart" enough to figure out the safety of this code by itself. > > len = read (sockfd, &hdr, sizeof (HEADER)); > > if (len < (ssize_t)sizeof (HEADER)) { > return 1; > } Perhaps inadvertently, splint is still drawing your attention to this code, which is still warranted, because it is still wrong, but for a different reason. Now the reason it is wrong is that just because read() returned less than you asked for, that *doesn't* mean there will never be any more. With disc files, this is probably so. With terminals, pipes, sockets, and several other kinds, it is definitely NOT so. This means that your program might give up when it could have succeeded. (It's hard to tell, because it can depend on a whole bunch of other things that are not apparent in this code snippet, neither to splint nor to me.) From the name 'sockfd' I surmise that you are reading from a socket. POSIX says that in that case, read() is equivalent to a call to recv() with no flags set. One of the flags you can set in recv() -- but not in read() -- is MSG_WAITALL, available for SOCKS_STREAM sockets, which says to wait until _all_ of the requested bytes are available. r = recv(sockfd, hdr, sizeof hdr, MSG_WAITALL); may well be what you want. Of course, splint probably doesn't know enough about this either, so whatever you do you will have to help splint out at this point. You probably already know about the /*@i@*/ annotation which switches off error reporting until the end of the line. I'd be inclined to do something like #ifdef S_SPLINT_S static ssize_t receive_header(/*@unused*/ int sockfd, HEADER /*@out@*/ *hdr) { static HEADER const dummy_header = {/* you know what to put here */}; *hdr = dummy_header; return -1; } #else #define receive_header(sockfd, hdr) recv(sockfd, hdr, sizeof *hdr, MSG_WAITALL) #endif and then change len = read(sockfd, hdr, sizeof (HEADER)); to len = receive_header(sockfd, &hdr); From Bob.van.der.Putten at KONE.com Tue Apr 8 04:36:19 2008 From: Bob.van.der.Putten at KONE.com (Putten Bob van der) Date: Tue, 8 Apr 2008 13:36:19 +0200 Subject: [splint-discuss] Parsing error Message-ID: <95871090E2A3D44AB645AD2D0AC2558918D0FA@TNLEXC01.KONENET.COM> I am new to Splint. I wrote the following code: unsigned int U0BRG = 0x3A1; U0BRG = 0x123; Will result in a parsing error However, unsigned int dada_U0BRG = 0x3A1; dada_U0BRG = 0x123; is accepted. Why?? With kind regards / Mit freundlichen Gr?ssen B.F.A. van der Putten Engineer D&D KONE Deursystemen BV Accustraat 21 3903 LX Veenendaal Postbus 94 3900 AB Veenendaal Tel. +31 (0) 318 532 333 Fax +31 (0) 318 532 339 bob.van.der.putten at kone.com Bezoek onze website www.kone.com voor informatie over levering en onderhoud van liften, roltrappen, rolpaden, gevelliftinstallaties en deursystemen. Op deze e-mail is de volgende disclaimer van toepassing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080408/9847a833/attachment.html From lholzheid at bihl-wiedemann.de Tue Apr 8 05:42:05 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Tue, 8 Apr 2008 14:42:05 +0200 Subject: [splint-discuss] Parsing error In-Reply-To: <95871090E2A3D44AB645AD2D0AC2558918D0FA@TNLEXC01.KONENET.COM> References: <95871090E2A3D44AB645AD2D0AC2558918D0FA@TNLEXC01.KONENET.COM> Message-ID: <20080408124205.GA16928@svr5.bihl-wiedemann.de> On Tue, 2008-04-08 13:36:19 +0200, Putten Bob van der wrote: > I am new to Splint. > > I wrote the following code: > unsigned int U0BRG = 0x3A1; > > > > U0BRG = 0x123; > > Will result in a parsing error Bob, I can't reproduce this. However, 'U0BRG' looks to me as a microcontroller register ("UART #0 baud rate register" or some such). Are you sure this is not a define which expands to something not conforming to the C standard? Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From lholzheid at bihl-wiedemann.de Tue Apr 8 06:31:09 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Tue, 8 Apr 2008 15:31:09 +0200 Subject: [splint-discuss] Parsing error In-Reply-To: <95871090E2A3D44AB645AD2D0AC2558918D0FD@TNLEXC01.KONENET.COM> References: <95871090E2A3D44AB645AD2D0AC2558918D0FD@TNLEXC01.KONENET.COM> Message-ID: <20080408133108.GB16928@svr5.bihl-wiedemann.de> On Tue, 2008-04-08 14:46:07 +0200, Putten Bob van der wrote: > Ludolf, > It is a special function register. > In the header file it is declared as: > sfr U0BRG = 0x3A1; /* UART 0 baud rate generator */ > > But Splint does not 'like' sfr. > > So I wrote: > > #ifdef S_SPLINT_S > #define sfr unsigned int > #endif So, the "unsigned int U0BRG = 0x3A1;" appears in a header, not in the body of a function (i.e. at 'file scope'). This is no valid C syntax. You'll have to write a version of the header that conforms to the C standard. Let the compiler use the original header and splint the new one by e.g. different '-I' command line flags for splint and compiler. HTH, Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From terry-splint at tenberry.com Tue Apr 8 08:15:40 2008 From: terry-splint at tenberry.com (Terry Colligan) Date: Tue, 8 Apr 2008 08:15:40 -0700 Subject: [splint-discuss] Parsing error In-Reply-To: <20080408133108.GB16928@svr5.bihl-wiedemann.de> References: <95871090E2A3D44AB645AD2D0AC2558918D0FD@TNLEXC01.KONENET.COM> <20080408133108.GB16928@svr5.bihl-wiedemann.de> Message-ID: <200804080815.41852.terry-splint@tenberry.com> On Tuesday 08 April 2008, Ludolf Holzheid wrote: > On Tue, 2008-04-08 14:46:07 +0200, Putten Bob van der wrote: > > Ludolf, > > It is a special function register. > > In the header file it is declared as: > > sfr U0BRG = 0x3A1; /* UART 0 baud rate generator */ > > > > But Splint does not 'like' sfr. > > > > So I wrote: > > > > #ifdef S_SPLINT_S > > #define sfr unsigned int > > #endif > > So, the "unsigned int U0BRG = 0x3A1;" appears in a header, not in the > body of a function (i.e. at 'file scope'). This is no valid C syntax. It certainly *is* valid C syntax. It's the definition of a global data variable (file scope) with an initialization. If you include this header in more than one source file, some implementations may complain about multiple definitions of U0BRG. > You'll have to write a version of the header that conforms to the C > standard. Let the compiler use the original header and splint the new > one by e.g. different '-I' command line flags for splint and compiler. > > HTH, > > Ludolf > -- Terry Terry Colligan terry-splint at tenberry.com From terry-splint at tenberry.com Tue Apr 8 08:15:40 2008 From: terry-splint at tenberry.com (Terry Colligan) Date: Tue, 8 Apr 2008 08:15:40 -0700 Subject: [splint-discuss] Parsing error In-Reply-To: <20080408133108.GB16928@svr5.bihl-wiedemann.de> References: <95871090E2A3D44AB645AD2D0AC2558918D0FD@TNLEXC01.KONENET.COM> <20080408133108.GB16928@svr5.bihl-wiedemann.de> Message-ID: <200804080815.41852.terry-splint@tenberry.com> On Tuesday 08 April 2008, Ludolf Holzheid wrote: > On Tue, 2008-04-08 14:46:07 +0200, Putten Bob van der wrote: > > Ludolf, > > It is a special function register. > > In the header file it is declared as: > > sfr U0BRG = 0x3A1; /* UART 0 baud rate generator */ > > > > But Splint does not 'like' sfr. > > > > So I wrote: > > > > #ifdef S_SPLINT_S > > #define sfr unsigned int > > #endif > > So, the "unsigned int U0BRG = 0x3A1;" appears in a header, not in the > body of a function (i.e. at 'file scope'). This is no valid C syntax. It certainly *is* valid C syntax. It's the definition of a global data variable (file scope) with an initialization. If you include this header in more than one source file, some implementations may complain about multiple definitions of U0BRG. > You'll have to write a version of the header that conforms to the C > standard. Let the compiler use the original header and splint the new > one by e.g. different '-I' command line flags for splint and compiler. > > HTH, > > Ludolf > -- Terry Terry Colligan terry-splint at tenberry.com From lholzheid at bihl-wiedemann.de Tue Apr 8 09:20:58 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Tue, 8 Apr 2008 18:20:58 +0200 Subject: [splint-discuss] Parsing error In-Reply-To: <200804080815.41852.terry-splint@tenberry.com> References: <95871090E2A3D44AB645AD2D0AC2558918D0FD@TNLEXC01.KONENET.COM> <20080408133108.GB16928@svr5.bihl-wiedemann.de> <200804080815.41852.terry-splint@tenberry.com> Message-ID: <20080408162058.GD16928@svr5.bihl-wiedemann.de> On Tue, 2008-04-08 08:15:40 -0700, Terry Colligan wrote: > On Tuesday 08 April 2008, Ludolf Holzheid wrote: > > > > So, the "unsigned int U0BRG = 0x3A1;" appears in a header, not in the > > body of a function (i.e. at 'file scope'). This is no valid C syntax. > > It certainly *is* valid C syntax. > It's the definition of a global data variable (file scope) with > an initialization. Ah, yes, of course, you are right. I do remember having problems with sfr declarations in system headers of IAR's MSP430 compiler and I solved it by writing my own version of the header. I don't exactly remember the problem, though... Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From Bob.van.der.Putten at KONE.com Thu Apr 10 23:07:19 2008 From: Bob.van.der.Putten at KONE.com (Putten Bob van der) Date: Fri, 11 Apr 2008 08:07:19 +0200 Subject: [splint-discuss] keyword 'near' Message-ID: <95871090E2A3D44AB645AD2D0AC2558918D109@TNLEXC01.KONENET.COM> Hello all, The following declaration resulted in a parsing error: long rmpa_instruction (short near *s1, short near *s2, unsigned short n); It seems that the word 'near' is the problem How can I solve this? With kind regards / Mit freundlichen Gr?ssen B.F.A. van der Putten Engineer D&D KONE Deursystemen BV Accustraat 21 3903 LX Veenendaal Postbus 94 3900 AB Veenendaal Tel. +31 (0) 318 532 333 Fax +31 (0) 318 532 339 bob.van.der.putten at kone.com Bezoek onze website www.kone.com voor informatie over levering en onderhoud van liften, roltrappen, rolpaden, gevelliftinstallaties en deursystemen. Op deze e-mail is de volgende disclaimer van toepassing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080411/1dbd56fb/attachment.html From roland.illig at gmx.de Thu Apr 10 23:36:40 2008 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 11 Apr 2008 07:36:40 +0100 Subject: [splint-discuss] keyword 'near' In-Reply-To: <95871090E2A3D44AB645AD2D0AC2558918D109@TNLEXC01.KONENET.COM> References: <95871090E2A3D44AB645AD2D0AC2558918D109@TNLEXC01.KONENET.COM> Message-ID: <47FF06F8.2080200@gmx.de> Putten Bob van der schrieb: > Hello all, > The following declaration resulted in a parsing error: > long rmpa_instruction (short near *s1, short near *s2, unsigned short n); > It seems that the word 'near' is the problem > How can I solve this? In a commonly used header file, which should be included very early by every source file, write: #ifdef S_SPLINT_S #define near /* nothing */ #endif SPlint doesn't need the information about near and far pointers; but sure, if someone was to hack SPlint's source code, it could analyze them too, and detect inconsistencies. But in almost all cases, your program will crash early anyway if you make a mistake in this area. Roland From boh at xa.nec-as.nec.com.cn Sun Apr 13 23:19:05 2008 From: boh at xa.nec-as.nec.com.cn (boh) Date: Mon, 14 Apr 2008 14:19:05 +0800 Subject: [splint-discuss] How fix "__gnuc_va_list" parse problem Message-ID: <20080414141858.FA5A.BOH@xa.nec-as.nec.com.cn> when splint my program, it produces like below: Splint 3.0.1.7 --- 24 Jan 2003 /usr/include/libio.h:464:18: Parse Error: Inconsistent function parameter syntax: __gnuc_va_list : . (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. Does someone help me thank you very much ! boh From giridhar at appaji.net Mon Apr 14 12:14:53 2008 From: giridhar at appaji.net (Y Giridhar Appaji Nag) Date: Tue, 15 Apr 2008 00:44:53 +0530 Subject: [splint-discuss] splint bugs on sourceforge.net Message-ID: <20080414191451.GC3873@loktak.appaji.net> Hi, Does someone monitor the bugs reported on splint at the sourceforge.net bugs / patches trackers? I filed a few bugs and atleast one patch there that Debain splint users have reported. Maybe some of them should make their way into the bugs page at http://www.splint.org/bugs.html Cheers, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080415/f28890b0/attachment.bin From charles.johnson at accre.vanderbilt.edu Tue Apr 22 13:48:14 2008 From: charles.johnson at accre.vanderbilt.edu (Charles Johnson) Date: Tue, 22 Apr 2008 15:48:14 -0500 Subject: [splint-discuss] Using /*@null@*/ Message-ID: <09983AD1-5C22-4824-A956-0257E39730D5@accre.vanderbilt.edu> I need a little help in using the /*@null@*/ annotation. I can't seem to find usage in the documentation. Here is the code snippet: typedef struct { FILE *logfp; int Threshold; int FacilityList; } mlog_t; mlog_t mlog = { (FILE *)NULL,0,0xffffffff }; splint produces this information: null.c:8:17: Global mlog.logfp initialized to null value: mlog.logfp = (FILE *)NULL A reference with no null annotation is assigned or initialized to NULL. Use /*@null@*/ to declare the reference as a possibly null pointer. (Use -nullassign to inhibit warning) If I alter the typdef like so: typedef struct { /*@null@*/ FILE *logfp; int Threshold; int FacilityList; } mlog_t; does not make splint happy. Making this change: mlog_t mlog = { /*@null@*/ (FILE *)NULL,0,0xffffffff }; gives a parse error, and splint stops. How should I be doing this, and where in the docs should I have found this? (splint -help annotations doesn't help either.) TIA Cheers-- Charles --- Charles Johnson Advanced Computing Center for Research and Education Vanderbilt University charles.johnson at accre.vanderbilt.edu Office: 615-343-2776 Cell: 615-478-8799 From Michael.Wojcik at MicroFocus.com Tue Apr 22 15:16:55 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Tue, 22 Apr 2008 15:16:55 -0700 Subject: [splint-discuss] Using /*@null@*/ In-Reply-To: <09983AD1-5C22-4824-A956-0257E39730D5@accre.vanderbilt.edu> References: <09983AD1-5C22-4824-A956-0257E39730D5@accre.vanderbilt.edu> Message-ID: <11352F9641010A418AD5057945A3A6590118B4D8@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Charles Johnson > Sent: Tuesday, 22 April, 2008 16:48 > > I need a little help in using the /*@null@*/ annotation. I > can't seem to find usage in the documentation. Here is the > code snippet: > > typedef struct { > FILE *logfp; > int Threshold; > int FacilityList; > } mlog_t; > > mlog_t mlog = { (FILE *)NULL,0,0xffffffff }; Put the annotation before the declaration of the pointer-type field that can be null: ----- #include typedef struct { /*@null@*/ FILE *foo; int bar; int baz; } foo_t; foo_t foo = { NULL, 0, 0xffffffff }; ----- That suppresses the null-assignment warning and parses successfully. (I determined this by experimentation; I don't know if it's documented anywhere.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus From john.carter at tait.co.nz Tue Apr 22 16:26:43 2008 From: john.carter at tait.co.nz (John Carter) Date: Wed, 23 Apr 2008 11:26:43 +1200 (NZST) Subject: [splint-discuss] Using /*@null@*/ In-Reply-To: <09983AD1-5C22-4824-A956-0257E39730D5@accre.vanderbilt.edu> References: <09983AD1-5C22-4824-A956-0257E39730D5@accre.vanderbilt.edu> Message-ID: On Tue, 22 Apr 2008, Charles Johnson wrote: > null.c:8:17: Global mlog.logfp initialized to null value: > mlog.logfp = (FILE *)NULL > If I alter the typdef like so: > > typedef struct { > /*@null@*/ FILE *logfp; > int Threshold; > int FacilityList; > } mlog_t; I would expect that annotation to resolve the 'plaint at null.c:8:17.... > does not make splint happy. ...but cause splint to insist you check that logfp is not NULL before you use elsewhere. Furthermore, splint may also be whinging about the fact you are overwriting whatever was in logfp without freeing it. ie. Splint might be happier.... but splint simply doesn't have a Shiny Happy nature. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter at tait.co.nz New Zealand From egore at iinet.net.au Tue Apr 22 18:55:54 2008 From: egore at iinet.net.au (Paul Spaapen) Date: Wed, 23 Apr 2008 09:55:54 +0800 Subject: [splint-discuss] How fix "__gnuc_va_list" parse problem In-Reply-To: <20080414141858.FA5A.BOH@xa.nec-as.nec.com.cn> References: <20080414141858.FA5A.BOH@xa.nec-as.nec.com.cn> Message-ID: <480E972A.9080009@iinet.net.au> I also had this issue, from what I read it seemed to be due to splint not recognising the built in type for the gcc library. Adding the command switch ?D__builtin_va_list=va_list seemed to fix the issue. boh wrote: > when splint my program, it produces like below: > > Splint 3.0.1.7 --- 24 Jan 2003 > > /usr/include/libio.h:464:18: Parse Error: > Inconsistent function parameter syntax: __gnuc_va_list : > . (For help on parse errors, see splint -help > parseerrors.) > *** Cannot continue. > > Does someone help me > > thank you very much ! > > > boh > > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss > > From egore at iinet.net.au Tue Apr 22 19:23:42 2008 From: egore at iinet.net.au (Paul Spaapen) Date: Wed, 23 Apr 2008 10:23:42 +0800 Subject: [splint-discuss] How fix "__gnuc_va_list" parse problem In-Reply-To: <480E972A.9080009@iinet.net.au> References: <20080414141858.FA5A.BOH@xa.nec-as.nec.com.cn> <480E972A.9080009@iinet.net.au> Message-ID: <480E9DAE.9040604@iinet.net.au> I was a bit too eager there... on closer look of your problem it was not the same error I was receiving. Sorry about that. Paul Paul Spaapen wrote: > I also had this issue, from what I read it seemed to be due to splint > not recognising the built in type for the gcc library. Adding the > command switch ?D__builtin_va_list=va_list seemed to fix the issue. > > boh wrote: > >> when splint my program, it produces like below: >> >> Splint 3.0.1.7 --- 24 Jan 2003 >> >> /usr/include/libio.h:464:18: Parse Error: >> Inconsistent function parameter syntax: __gnuc_va_list : >> . (For help on parse errors, see splint -help >> parseerrors.) >> *** Cannot continue. >> >> Does someone help me >> >> thank you very much ! >> >> >> boh >> >> _______________________________________________ >> splint-discuss mailing list >> splint-discuss at mail.cs.virginia.edu >> http://www.cs.virginia.edu/mailman/listinfo/splint-discuss >> >> >> > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss > > From Carsten.Agger at tietoenator.com Wed Apr 23 02:08:01 2008 From: Carsten.Agger at tietoenator.com (Carsten.Agger at tietoenator.com) Date: Wed, 23 Apr 2008 11:08:01 +0200 Subject: [splint-discuss] Introduction and splint patterns Message-ID: First of all, I'd like to introduce myself: My name is Carsten Agger, and I work as a software engineer with TietoEnator A/S in Aarhus, Denmark. I'm running a large program through splint, and while I understand most of its warnings and can make an appropriate correction, sometimes I see a pattern that makes me bang my head against the wall, because yes, I see the problem or at least why splint might think there is a problem but no, the code is correct, I just don't know how to convince splint of that fact - especially since the warnings that would have to be turned off is often too generic - like compmempass, compdef, etc. If such questions are inappropriate for this list, please let me know. An example: Pattern: COMPDEF, assigned member Template: struct_type s; member_type m; s = << ... >> s.m = &m; m.a = << ... >>; m.b = << ... >>; m.c = << ... >>; my_function( ..., s, ...); Warning: Passed storage *(s.m) contains 3 undefined fields ... Storage derivable from a parameter, return value or global is not defined. Use /*@out@*/ to denote passed or returned storage which need not be defined. (Use -compdef to inhibit warning) ---------------- A possible solution to this is to assign to the struct member explicitly: s.m->a = << ... >>; s.m->b = << ... >>; s.m->c = << ... >>; But this is not very satisfactory - as I see it, splint might be able to figure that if m's fields are initialized, then s.m is also initialized. Is there some other annotation I could use? /*@-compdef@*/ is far too generic to be useful here (the function might e.g. take other parameters that I do want splint to check). best regards, Carsten Agger, Aarhus, Denmark http://www.tietoenator.com From Michael.Wojcik at MicroFocus.com Wed Apr 23 05:59:24 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed, 23 Apr 2008 05:59:24 -0700 Subject: [splint-discuss] Using /*@null@*/ In-Reply-To: <11352F9641010A418AD5057945A3A6590118B4D8@MTV-EXCHANGE.microfocus.com> References: <09983AD1-5C22-4824-A956-0257E39730D5@accre.vanderbilt.edu> <11352F9641010A418AD5057945A3A6590118B4D8@MTV-EXCHANGE.microfocus.com> Message-ID: <11352F9641010A418AD5057945A3A6590118B4DB@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Michael Wojcik > Sent: Tuesday, 22 April, 2008 18:17 > > Put the annotation before the declaration of the pointer-type > field that can be null: > > ----- > #include > > typedef struct { > /*@null@*/ FILE *foo; > int bar; > int baz; > } foo_t; > > foo_t foo = { NULL, 0, 0xffffffff }; > ----- > > That suppresses the null-assignment warning and parses successfully. Hmm. I missed the statement in your initial note that said you tried this and it "does not make splint happy". What didn't work? In my tests that properly annotated the pointer as allowing a null value. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From Michael.Wojcik at microfocus.com Wed Apr 23 05:59:25 2008 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 23 Apr 2008 05:59:25 -0700 Subject: [splint-discuss] How fix "__gnuc_va_list" parse problem In-Reply-To: <480E972A.9080009@iinet.net.au> References: <20080414141858.FA5A.BOH@xa.nec-as.nec.com.cn> <480E972A.9080009@iinet.net.au> Message-ID: <11352F9641010A418AD5057945A3A6590118B4DC@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Paul Spaapen > Sent: Tuesday, 22 April, 2008 21:56 > > I also had this issue, from what I read it seemed to be due > to splint not recognising the built in type for the gcc > library. Adding the command switch > -D__builtin_va_list=va_list seemed to fix the issue. The root problem is that Splint is a C implementation, and gnuc is not. If you use Gnu extensions in your C sources, then Splint will have trouble with them. (The same applies, of course, to eg Microsoft extensions, and so on.) Often this can be worked around by telling Splint to treat the problematic construct as something innocuous, since Splint merely does translation and does not product executable code. But in order to do that you need to know the entire problem in its context, and not just the error message - which is all the OP provided. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From Carsten.Agger at tietoenator.com Wed Apr 23 07:21:45 2008 From: Carsten.Agger at tietoenator.com (Carsten.Agger at tietoenator.com) Date: Wed, 23 Apr 2008 16:21:45 +0200 Subject: [splint-discuss] Passed storage is stack Message-ID: Here's another splint warning pattern which occurs very frequently in the code I'm reviewing: struct_type s; member_type m; s = << ... >> s.m = &m; f(..., ..., &s, ..., ...); Storage m.s reachable from passed parameter is stack (should be implicitly only): &s Storage derivable from a parameter does not match the alias kind expected for the formal parameter. (Use -compmempass to inhibit warning) Enclosing the function call in /*@-compmempass@*/ ... /*@=compmempass@*/ would once again not be a great option since we actually want the other parameters checked. So what to do? What I'd really like is to tell lint that yes, this storage is on the stack, but since the function f will neither deallocate it nor keep it, this is quite okay. I've tried to annotate the parameter corresponding to the structure (&s) as /*@dependent@*/, and I've even tried to annotate the structure member (s.m) as /*@dependent@*/ too, but the warning against stack storage continues. Of course, an easy way out is: s.m = (member_type *) malloc(sizeof(member_type)); f(..., ..., &s, ..., ...); free(s.m); ... but while it actually works, it is not satisfactory - the first construction seems perfectly all right from a memory management perspective, so I'd like a way to tell splint it's okay. Any suggestions, TIA & br Carsten From Michael.Wojcik at MicroFocus.com Wed Apr 23 08:26:46 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed, 23 Apr 2008 08:26:46 -0700 Subject: [splint-discuss] Passed storage is stack In-Reply-To: References: Message-ID: <11352F9641010A418AD5057945A3A6590118B4E5@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Carsten.Agger at tietoenator.com > Sent: Wednesday, 23 April, 2008 10:22 > > Here's another splint warning pattern which occurs very > frequently in the code I'm reviewing: > > struct_type s; > member_type m; > > s = << ... >> > > s.m = &m; > > f(..., ..., &s, ..., ...); > > > Storage m.s reachable from passed parameter is stack (should > be implicitly only): &s > Storage derivable from a parameter does not match the alias > kind expected for > the formal parameter. (Use -compmempass to inhibit warning) I believe this is a bug (or more precisely a missing feature): there's no annotation currently supported by Splint to tell it that this parameter to f can point to stack-allocated storage. That's what should be annotated, IMO - the formal parameter in the declaration of f. That is, what we want is something like: int f(/*@notkept@*/ int *p); to tell Splint that the storage allocated by p is not kept by f, so it doesn't matter if it's stack. But there is no such annotation. That's what happens when you use a free, open-source code analyzer that's been largely unmaintained for years: you find bugs. Static code analysis is a hard problem, which is why there are fancy commercial products. I'm afraid your choices are basically to put up with the error (or with a less-satisfactory solution such as disabling compmempass around the offending line), fix Splint yourself, or use another code analyzer. (After several years of hibernation, there *is* renewed work on Splint, with the 3.1.2 release last year and occasional fixes in the CVS sources since. The developers certainly deserve credit for that - quite a few bugs were fixed in 3.1.2. But there aren't many active developers and complex problems are not likely to be fixed quickly; the most recent change was two months ago, I think.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus From Carsten.Agger at tietoenator.com Wed Apr 23 23:37:22 2008 From: Carsten.Agger at tietoenator.com (Carsten.Agger at tietoenator.com) Date: Thu, 24 Apr 2008 08:37:22 +0200 Subject: [splint-discuss] Passed storage is stack References: <11352F9641010A418AD5057945A3A6590118B4E5@MTV-EXCHANGE.microfocus.com> Message-ID: > >> Here's another splint warning pattern which occurs very >> frequently in the code I'm reviewing: >> >> struct_type s; >> member_type m; >> >> s = << ... >> >> >> s.m = &m; >> >> f(..., ..., &s, ..., ...); > > >I believe this is a bug (or more precisely a missing feature): there's >no annotation currently supported by Splint to tell it that this >parameter to f can point to stack-allocated storage. That's what should >be annotated, IMO - the formal parameter in the declaration of f. > >That is, what we want is something like: > > int f(/*@notkept@*/ int *p); Thanks a lot! Yes, it would seem like a bug, because if splint assumes the storage is kept, the other solution (of malloc'ing and subsequently free'ing) isn't really better, so to be consistent, splint should complain in *both* cases - and it doesn't. As it happens, the problem seems to arise mainly with structs with pointer members allocated on the stack - splint does not complain about the struct s itself (which is also stack), only s.m. >That's what happens when you use a free, open-source code analyzer >that's been largely unmaintained for years: you find bugs. Static code >analysis is a hard problem, which is why there are fancy commercial >products. I'm afraid your choices are basically to put up with the error >(or with a less-satisfactory solution such as disabling compmempass >around the offending line), fix Splint yourself, or use another code >analyzer. Unfortunately, I can't decide which code analyzer to use, this is a more strategic decision in the project - so I'll have to find a way around. Thanks for the input, anyway! br Carsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3733 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080424/e68d6078/attachment-0001.bin From john.carter at tait.co.nz Sun Apr 27 16:15:11 2008 From: john.carter at tait.co.nz (John Carter) Date: Mon, 28 Apr 2008 11:15:11 +1200 (NZST) Subject: [splint-discuss] Passed storage is stack In-Reply-To: References: Message-ID: On Wed, 23 Apr 2008, Carsten.Agger at tietoenator.com wrote: > > Here's another splint warning pattern which occurs very frequently in the code I'm reviewing: > > struct_type s; > member_type m; > > s = << ... >> > > s.m = &m; > > f(..., ..., &s, ..., ...); > > > Storage m.s reachable from passed parameter is stack (should be implicitly only): &s > Storage derivable from a parameter does not match the alias kind expected for > the formal parameter. (Use -compmempass to inhibit warning) Again it is a matter of explaining to splint, in the declaration your intent. By default splint doesn't know your intend that f makes just brief us of it and doesn't hold onto that pointer. The mistake we usually make on seeing splint is to assume it analyses f first, and then on the basis of that knowledge analyses the uses of f. Nope, it doesn't and perhaps more importantly, shouldn't do that. It just looks at the declaration of f, makes certain (documented in the manual) assumptions about it and then checks the client AND the implementation on that basis. ie. You haven't told splint what f will do with that pointer, so it's made some reasonable, but in this case false assumptions about it. In fact, this warning will catch a largish number of standard newbie to C bugs. So assuming you're not a newbie to C and you know what you are doing.... and know the danger of pointers to items on the stack... You have to go to the declaration of f, in particular the declaration of the pointer parameter you are using, and annotate that. This is actually a _very_ good thing. Assuming you aren't the only person maintaining this code... then perhaps in a couple of months somebody comes along and changes the implementation of f to hold on to that pointer. "f" perhaps still works fine for the invocation that person is testing it on, but now has a bug in the invocation you have before you! If you don't use splint, or have just told splint to "shut up", that bug will probably only be found by the customer... With splint, and that annotation you have supplemented the declaration of "f" with an important bit of documentation, "f" must not hold on to that pointer, in some cases it will go invalid immediately after return. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter at tait.co.nz New Zealand From john.carter at tait.co.nz Sun Apr 27 15:57:50 2008 From: john.carter at tait.co.nz (John Carter) Date: Mon, 28 Apr 2008 10:57:50 +1200 (NZST) Subject: [splint-discuss] Introduction and splint patterns In-Reply-To: References: Message-ID: On Wed, 23 Apr 2008, Carsten.Agger at tietoenator.com wrote: > I'm running a large program through splint, and while I understand > most of its warnings and can make an appropriate correction, > sometimes I see a pattern that makes me bang my head against the > wall, because yes, I see the problem or at least why splint might > think there is a problem but no, the code is correct, I just don't > know how to convince splint of that fact - especially since the > warnings that would have to be turned off is often too generic - > like compmempass, compdef, etc. The advice I give our guys here is, annotate the declarations to explain to splint what your intent is, rather than tell splint to shut up. Often if a typedef is too complex (read two levels or more) splint doesn't understand it. That's OK, most human programmers won't understand it either, so break it into smaller levels and typedef and annotate those. > struct_type s; > member_type m; > > s = << ... >> > > s.m = &m; > > m.a = << ... >>; > m.b = << ... >>; > m.c = << ... >>; > > my_function( ..., s, ...); > > Warning: > > Passed storage *(s.m) contains 3 undefined fields ... > Storage derivable from a parameter, return value or global is not defined. > Use /*@out@*/ to denote passed or returned storage which need not be defined. > (Use -compdef to inhibit warning) I think whether m is defined or not is not the issue. I think splint is looking no further than the type and annotation on s.m! ie. If you need to convince splint that s.m points to a fully defined object, ie. you need to annotate the m field on struct_type. typedef struct { /*@SOME_ANNOTATION_HERE@*/ member_type * m; } struct_type; Which of course may have interesting implications on the rest of your usage of that struct type. ie. The annotation/type will then say, field m _always_ points to a fully defined member_type_type. Conversely, you can argue that if m ever points to something other that a fully defined member_type, you effectively have a different type, but you have just used a lazy shorthand and not given it a different name. Splint gives the appearance of intelligence, actually it's just paying very close attention to the strict typing system, and on each individual hand over from this type to that type. As far as I can see it doesn't pay much attention to the end-to-end data flow. But that's OK, if you behave yourself in a very strictly well behaved manner on each individual step, the end-to-end will be OK. If you ever, so much as once, tell splint to shut up on any individual step, well, your guarantees of end-to-end sanity have gone and you back to the individual programmer smiling beatifically and saying "Trust Me!" John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter at tait.co.nz New Zealand From ok at cs.otago.ac.nz Wed Apr 30 03:17:58 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 30 Apr 2008 22:17:58 +1200 Subject: [splint-discuss] Parse error with @ from the IAR compiler In-Reply-To: References: Message-ID: <304FE293-2E95-42D2-A83F-729389729536@cs.otago.ac.nz> > > int myVar @ 0xFFE0; > Use #ifdef S_SPLINT_S #define at(x) #else #define at(x) @x #endif ... int myVar at(0xFFE0); > > -D@="; //" This makes no sense: C syntax only allows you to #define identifiers, and @ is not in the C alphabet. I'm sure you can write a script in your favourite scripting language (sed, awk, perl, tcl, python, ...) to change '@ ' into 'at()'. From Michael.Wojcik at MicroFocus.com Wed Apr 30 06:33:33 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed, 30 Apr 2008 06:33:33 -0700 Subject: [splint-discuss] Parse error with @ from the IAR compiler In-Reply-To: <304FE293-2E95-42D2-A83F-729389729536@cs.otago.ac.nz> References: <304FE293-2E95-42D2-A83F-729389729536@cs.otago.ac.nz> Message-ID: <11352F9641010A418AD5057945A3A6590118B515@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Richard A. O'Keefe > Sent: Wednesday, 30 April, 2008 06:18 > > > > -D@="; //" > > This makes no sense: C syntax only allows you to #define > identifiers, and @ is not in the C alphabet. Actually, I believe an implementation is allowed, though not required, to support this. ISO 9899-1990 ("C90") 5.2.1 allows the source character set to include additional characters ("at least the following members"). It ends with the note: "If any other characters are encountered in a source file (except in a character constant, a stirng literal, a header name, a comment, or a preprocessing token that is never converted to a token), the behavior is undefined." That might seem to contradict the implicit permission to add characters to the source character set. However, in this particular case - defining "@" as the name of an object-style macro - "@" will be a preprocessing token that is never converted to a token. See 5.1.1.2 #3 - #7; macro expansion happens long before pp-tokens are converted to tokens. ISO 9899-1999 plus corregenda ("C99") clarifies this situation, noting that both the source character set and the execution character set can be extended with additional locale-specific members. It even allows multibyte characters in the source character set, including multibyte character sequences in identifiers (5.2.1.2). In this case, of course, the implementation is Splint. And Splint doesn't add "@" to the source character set, so the discussion is moot. Your solution is definitely a better one. (I'm not sure I'd use "at" as a function-style macro name, but that's a matter of style.) Splint is a source analyzer for C, not for languages which look like C but have special syntactic extensions. Developers who want to use Splint should write C, and let their implementation translate it into not-quite-C as necessary, using macros. -- Michael Wojcik Principal Software Systems Developer, Micro Focus