From groove at tu-clausthal.de Wed Jan 4 18:07:41 2006 From: groove at tu-clausthal.de (Tobias Tietze) Date: Wed Mar 22 17:11:20 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) Message-ID: <43BC553D.7040706@tu-clausthal.de> Hi there, i am new to Splint and i read much of the list, but i still habe my problem. It is that i need to subsitude #asm in my code somehow. My Code contains often parts like, #asm ("sei") or #asm("wdr") and i thought i could somehow use a macro to substitude #asm with __asm__ for example, because __asm__ splint understands. But you cannot use: #define #asm __asm__ or -D#asm=__asm__ because splint fails with that. Is there a workaround for such a thing. Thanke you, Tobias. From piotr at pisi.com.pl Thu Jan 5 15:44:40 2006 From: piotr at pisi.com.pl (Piotr Piatek) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) In-Reply-To: <43BC553D.7040706@tu-clausthal.de> References: <43BC553D.7040706@tu-clausthal.de> Message-ID: On Thu, 05 Jan 2006 00:07:41 +0100, Tobias Tietze wrote: >i am new to Splint and i read much of the list, >but i still habe my problem. >It is that i need to subsitude #asm in my code somehow. >My Code contains often parts like, >#asm ("sei") or #asm("wdr") >and i thought i could somehow use a macro to substitude #asm >with __asm__ for example, because __asm__ splint understands. >But you cannot use: >#define #asm __asm__ or -D#asm=__asm__ because splint fails with that. >Is there a workaround for such a thing. You can exclude the asm statements from Splint checking by surrounding them with the #ifndef S_SPLINT_S and #endif pair. That's what I do. Piotr From brian.quinlan at iolfree.ie Fri Jan 6 16:45:27 2006 From: brian.quinlan at iolfree.ie (Brian Quinlan) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) In-Reply-To: <43BC553D.7040706@tu-clausthal.de> References: <43BC553D.7040706@tu-clausthal.de> Message-ID: <1136583928.5102.14.camel@akebono> Hi Tobias, Generally you'll get better help from the list if you provide sample code and splint output, so that people can see exactly what the problem is. Can you post the code and output? It might not be necessary to use S_SPLINT_S every time you use #asm. Bye, Brian On Thu, 2006-01-05 at 00:07 +0100, Tobias Tietze wrote: > Hi there, > > i am new to Splint and i read much of the list, > but i still habe my problem. > It is that i need to subsitude #asm in my code somehow. > My Code contains often parts like, > #asm ("sei") or #asm("wdr") > and i thought i could somehow use a macro to substitude #asm > with __asm__ for example, because __asm__ splint understands. > But you cannot use: > #define #asm __asm__ or -D#asm=__asm__ because splint fails with that. > Is there a workaround for such a thing. > > Thanke you, > > Tobias. > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss From groove at tu-clausthal.de Sun Jan 8 16:30:14 2006 From: groove at tu-clausthal.de (Tobias Tietze) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) Message-ID: <43C18466.8030904@tu-clausthal.de> Hello Piotr and Brian. Thanks for the answers. @Piotr That is the thing i did too, but i wanted it a little more comfortable, because i had much things to exclude. @Brian I have C-code for embedded Processors and some #asm (" wdr ") in my code. Splint output for that: example.c:803:31: Unrecognized pre-processor directive: #asm( "wdr" ); Pre-processor directive is not recognized. (Use -unrecogdirective to inhibit warning) and i have parts with: #ifdef S_SPLINT_S #define ALARM_LED int #define LED_OFF 1 #endif ALARM_LED = LED_OFF; Splint output for that: primary.c:677:12: Parse Error. (For help on parse errors, see splint -help parseerrors.) but ALARM_LED is still a parse Error. I need to use the way: #ifndef S_SPLINT_S ... #endif It would be great if i could define all only once for example in an extra Header and in the .splintrc file. But for now i must edit the Source Code too often directly. That is my problem. If someone knows a better way ? Thank you, Tobias. From piotr at pisi.com.pl Sun Jan 8 17:47:21 2006 From: piotr at pisi.com.pl (Piotr Piatek) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) In-Reply-To: <43C18466.8030904@tu-clausthal.de> References: <43C18466.8030904@tu-clausthal.de> Message-ID: On Sun, 08 Jan 2006 22:30:14 +0100, Tobias Tietze wrote: >and i have parts with: >#ifdef S_SPLINT_S >#define ALARM_LED int >#define LED_OFF 1 >#endif > >ALARM_LED = LED_OFF; The preprocessor evaluates this to: int = 1; which is actually nonsense. You should apply Splint only to programs which compile without errors. Quoted from your first post: >But you cannot use: >#define #asm __asm__ Wrong order of arguments! The #define directive expects the name of the defined macro first, then the string that should replace the macro. I have tried to adapt a sample Turbo C program containing asm statements to Splint requirements. Original version which cannot be parsed by Splint: int main(void) { asm cli; return 0; } Modified version which successfully passes the Splint checking: #ifdef S_SPLINT_S #define __asm__(x) #else #define __asm__(x) asm x #endif int main (void) { __asm__(cli); return 0; } Hope this helps... Piotr From brian.quinlan at iolfree.ie Sun Jan 8 22:14:02 2006 From: brian.quinlan at iolfree.ie (Brian Quinlan) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) In-Reply-To: <43C18466.8030904@tu-clausthal.de> References: <43C18466.8030904@tu-clausthal.de> Message-ID: <1136776442.5978.6.camel@akebono> Hi Tobias, The warnings generated by splint are often quite helpful and will often tell what you need to do to turn off the warning if you're sure that's the right thing to do. You can use -unrecogdirective on the command-line to suppress the warning for #asm. See the example below. BTW, for what it's worth, I agree with what Piotr says about "int = 1;" Bye, Brian [brian@akebono tmp]$ cat splintPreprocessorTest.c #include void func(void) { #asm blah blah blah printf("This is a test.\n"); } [brian@akebono tmp]$ splint splintPreprocessorTest.c Splint 3.1.1 --- 15 Jun 2004 splintPreprocessorTest.c: (in function func) splintPreprocessorTest.c:5:21: Unrecognized pre-processor directive: #asm blah blah blah Pre-processor directive is not recognized. (Use -unrecogdirective to inhibit warning) Finished checking --- 1 code warning [brian@akebono tmp]$ splint -unrecogdirective splintPreprocessorTest.c Splint 3.1.1 --- 15 Jun 2004 Finished checking --- no warnings On Sun, 2006-01-08 at 22:30 +0100, Tobias Tietze wrote: <> > @Brian > I have C-code for embedded Processors and some > #asm (" wdr ") > in my code. > Splint output for that: > example.c:803:31: Unrecognized pre-processor directive: #asm( "wdr" ); > Pre-processor directive is not recognized. (Use -unrecogdirective to > inhibit > warning) > <> From piotr at pisi.com.pl Mon Jan 9 03:14:22 2006 From: piotr at pisi.com.pl (Piotr Piatek) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] Preprocessor Substitude (Embedded) In-Reply-To: <1136776442.5978.6.camel@akebono> References: <43C18466.8030904@tu-clausthal.de> <1136776442.5978.6.camel@akebono> Message-ID: On Mon, 09 Jan 2006 03:14:02 +0000, Brian Quinlan wrote: >The warnings generated by splint are often quite helpful and will often >tell what you need to do to turn off the warning if you're sure that's >the right thing to do. You can use -unrecogdirective on the command-line >to suppress the warning for #asm. This seems to be the best solution, indeed. If the asm statements start with # then they are apparently handled by the preprocessor, and I doubt that a preprocessor directive could be substituted with a macro. My example program was pointless here. Piotr From benjl at cse.unsw.edu.au Mon Jan 9 07:24:11 2006 From: benjl at cse.unsw.edu.au (Benno) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] /*@null@*/ and arrays Message-ID: <20060109122411.GA12613@cse.unsw.edu.au> I have a very small program for which I really can't see what the reason for the error is: """ static char *args[10]; static void foo(void) /*@globals args @*/ /*@modifies args @*/ { args[0] = 0; return; } int main(void) /*@globals args @*/ /*@modifies args @*/ { foo(); return 1; } """ Running splint produces: test.c: (in function foo) test.c:9:9: Function returns with null storage derivable from global args[0] 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) test.c:8:12: Storage args[0] becomes null If I change line 8 to be "args[1] = 0", then no error is produced. If anyone can please explain this error I'd be really grateful. Cheers, Benno From Michael.Wojcik at MicroFocus.com Mon Jan 9 08:03:29 2006 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed Mar 22 17:11:21 2006 Subject: [splint-discuss] /*@null@*/ and arrays Message-ID: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Benno > Sent: Monday, 09 January, 2006 07:24 > > I have a very small program for which I really can't see > what the reason for the error is: > > """ > static char *args[10]; > > static void > foo(void) > /*@globals args @*/ > /*@modifies args @*/ > { > args[0] = 0; Here you set args[0] to null. (0 in a pointer context is a null pointer constant.) > return; > } > > int > main(void) > /*@globals args @*/ > /*@modifies args @*/ > { > foo(); args is global, so when foo() returns, main now has access to a null pointer that may not have been null before. (That's only as far as Splint is concerned - strictly speaking, in this test program args[0] must have been null throughout the life of this test program, because it's a file-scope variable and thus is initialized to the equivalent of {0}, which for a pointer variable is null.) > return 1; > } > """ > > Running splint produces: > > test.c: (in function foo) > test.c:9:9: Function returns with null storage derivable from > global args[0] This tells you that when foo() returns, it's in effect returning a null pointer, because args is global. > 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) > test.c:8:12: Storage args[0] becomes null > > If I change line 8 to be "args[1] = 0", then no error is produced. That appears to be a bug in Splint. It shouldn't make any difference which element of args you set to null; the effect is the same as far as returning with a global pointer set to null. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From benjl at cse.unsw.edu.au Mon Jan 9 16:05:01 2006 From: benjl at cse.unsw.edu.au (Benno) Date: Wed Mar 22 17:11:22 2006 Subject: [splint-discuss] /*@null@*/ and arrays In-Reply-To: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> References: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> Message-ID: <20060109210501.GA6183@cse.unsw.edu.au> On Mon Jan 09, 2006 at 05:03:29 -0800, Michael Wojcik wrote: >> From: splint-discuss-bounces@cs.virginia.edu >> [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Benno >> Sent: Monday, 09 January, 2006 07:24 >> >> I have a very small program for which I really can't see >> what the reason for the error is: >> >> """ >> static char *args[10]; >> >> static void >> foo(void) >> /*@globals args @*/ >> /*@modifies args @*/ >> { >> args[0] = 0; > >Here you set args[0] to null. (0 in a pointer context is a null pointer >constant.) > >> return; >> } >> >> int >> main(void) >> /*@globals args @*/ >> /*@modifies args @*/ >> { >> foo(); > >args is global, so when foo() returns, main now has access to a null >pointer that may not have been null before. (That's only as far as >Splint is concerned - strictly speaking, in this test program args[0] >must have been null throughout the life of this test program, because >it's a file-scope variable and thus is initialized to the equivalent of >{0}, which for a pointer variable is null.) > >> return 1; >> } >> """ >> >> Running splint produces: >> >> test.c: (in function foo) >> test.c:9:9: Function returns with null storage derivable from >> global args[0] > >This tells you that when foo() returns, it's in effect returning a null >pointer, because args is global. > >> 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) >> test.c:8:12: Storage args[0] becomes null >> >> If I change line 8 to be "args[1] = 0", then no error is produced. > >That appears to be a bug in Splint. It shouldn't make any difference >which element of args you set to null; the effect is the same as far as >returning with a global pointer set to null. Hi Michael, Thanks for the explanation. That does make sense. I guess my real question is how can I annotate things to specify that it is valid for things in the array to be null? I found examples for how to specify that fields in a struct can be null, but no equivilant for arrays. In the actual program (which is too long to post here), the args array is being passed to execvp, and setting an entry to NULL is required to indicate the end of the array. Currently I am working around it by using the /*@i@*/ syntax, but that feels dirty having to resort to that. Cheers, Benno From ptp at lysator.liu.se Mon Jan 9 19:12:36 2006 From: ptp at lysator.liu.se (Tommy Pettersson) Date: Wed Mar 22 17:11:22 2006 Subject: [splint-discuss] /*@null@*/ and arrays In-Reply-To: <20060109210501.GA6183@cse.unsw.edu.au> References: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> <20060109210501.GA6183@cse.unsw.edu.au> Message-ID: <20060110001236.GA15252@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> On Tue, Jan 10, 2006 at 08:05:01AM +1100, Benno wrote: > I guess my real > question is how can I annotate things to specify that it is valid for > things in the array to be null? I found examples for how to specify > that fields in a struct can be null, but no equivilant for arrays. It's hidden under section 5.2.7 in the splint manual. Any annotation always applies to the outermost level of storage, so you have to define (and annotate there) a type for the array elements. typedef /*@null@*/ char* foo_t; static foo_t args[10]; but with a better name for the type. -- Tommy Pettersson From benjl at cse.unsw.edu.au Tue Jan 10 01:25:34 2006 From: benjl at cse.unsw.edu.au (Benno) Date: Wed Mar 22 17:11:22 2006 Subject: [splint-discuss] /*@null@*/ and arrays In-Reply-To: <20060110001236.GA15252@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> References: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> <20060109210501.GA6183@cse.unsw.edu.au> <20060110001236.GA15252@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> Message-ID: <20060110062534.GX18649@cse.unsw.edu.au> On Tue Jan 10, 2006 at 01:12:36 +0100, Tommy Pettersson wrote: >On Tue, Jan 10, 2006 at 08:05:01AM +1100, Benno wrote: >> I guess my real >> question is how can I annotate things to specify that it is valid for >> things in the array to be null? I found examples for how to specify >> that fields in a struct can be null, but no equivilant for arrays. > >It's hidden under section 5.2.7 in the splint manual. >Any annotation always applies to the outermost level of >storage, so you have to define (and annotate there) a type >for the array elements. > > typedef /*@null@*/ char* foo_t; > static foo_t args[10]; > >but with a better name for the type. Cool thanks, I'm getting closer I think. So I now have: typedef /*@null@*/ char* char_p; static char_p args[MAX_ARGS]; and then do: execvp(args[0], args); It now complains that args[0] might be null, which is actually a really good warning, but it also complains args[] might be null, which I presume is because execvp isn't declared in such a way as to expect one of those pointers in that array to be null. I'm sure the answer to the args[0] problem is in the manual somewhere and I just haven't found it, but I really can't work out the args[] bit by myself, as far as I can tell the problem is that execvp is defined to take "char *args[]", and that can't deal with the fact that it might be null. Should I somehow define the execvp function to take an array with pointers that may be null? Thanks for you patience, Benno From ptp at lysator.liu.se Tue Jan 10 05:30:33 2006 From: ptp at lysator.liu.se (Tommy Pettersson) Date: Wed Mar 22 17:11:23 2006 Subject: [splint-discuss] /*@null@*/ and arrays In-Reply-To: <20060110062534.GX18649@cse.unsw.edu.au> References: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> <20060109210501.GA6183@cse.unsw.edu.au> <20060110001236.GA15252@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> <20060110062534.GX18649@cse.unsw.edu.au> Message-ID: <20060110103033.GA17293@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> On Tue, Jan 10, 2006 at 05:25:34PM +1100, Benno wrote: > I'm getting closer I think. So I now have: > > > typedef /*@null@*/ char* char_p; > static char_p args[MAX_ARGS]; > > and then do: > > > execvp(args[0], args); > > It now complains that args[0] might be null, which is actually a > really good warning, but it also complains args[] might be null, which > I presume is because execvp isn't declared in such a way as to expect > one of those pointers in that array to be null. The obvious solution to the first warning, which indeed is good warning, is of course: if (args[0] != 0) { execvp(args[0], ... } else { fprintf(stderr, "Error: no program to execute"); ... } Or, if your design is supposed to never pass a null args[0]: assert(args[0] != 0); execvp(args[0], ... I don't understand why splint thinks args[] can be null, but if the warning is for the execvp() call, an additional assert that (args != 0) should fix it. -- Tommy Pettersson From benjl at cse.unsw.edu.au Tue Jan 10 16:47:08 2006 From: benjl at cse.unsw.edu.au (Benno) Date: Wed Mar 22 17:11:23 2006 Subject: [splint-discuss] /*@null@*/ and arrays In-Reply-To: <20060110103033.GA17293@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> References: <11352F9641010A418AD5057945A3A6591F135D@MTV-EXCHANGE.microfocus.com> <20060109210501.GA6183@cse.unsw.edu.au> <20060110001236.GA15252@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> <20060110062534.GX18649@cse.unsw.edu.au> <20060110103033.GA17293@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se> Message-ID: <20060110214708.GA25095@cse.unsw.edu.au> On Tue Jan 10, 2006 at 11:30:33 +0100, Tommy Pettersson wrote: >On Tue, Jan 10, 2006 at 05:25:34PM +1100, Benno wrote: >> I'm getting closer I think. So I now have: >> >> >> typedef /*@null@*/ char* char_p; >> static char_p args[MAX_ARGS]; >> >> and then do: >> >> >> execvp(args[0], args); >> >> It now complains that args[0] might be null, which is actually a >> really good warning, but it also complains args[] might be null, which >> I presume is because execvp isn't declared in such a way as to expect >> one of those pointers in that array to be null. > >The obvious solution to the first warning, which indeed is >good warning, is of course: > > if (args[0] != 0) { > execvp(args[0], ... > } else { > fprintf(stderr, "Error: no program to execute"); > ... > } > >Or, if your design is supposed to never pass a null args[0]: > > assert(args[0] != 0); > execvp(args[0], ... Ok, great, that works. >I don't understand why splint thinks args[] can be null, >but if the warning is for the execvp() call, an additional >assert that (args != 0) should fix it. That error seemed to go away with the assert. Thanks a lot everyone, I've now managed to fix all my warnings. Cheers, Benno From gmack at innerfire.net Sun Jan 29 08:06:06 2006 From: gmack at innerfire.net (Gerhard Mack) Date: Wed Mar 22 17:11:23 2006 Subject: [splint-discuss] not sure how to annotate items returned from a linked list Message-ID: hello, I'm just starting to use splint on a project I'm working on and I can't quite figgure out how to annotate a function that returns a list item. Any help would be appreciated. Right now I get: src/lobbys.c:97:19: Function returns with global masteravaillist referencing released storage src/lobbys.c:97:8: Storage masteravaillist released the struct is defined as: /*@abstract@*/ struct availlist { /*@null@*/ /*@dependent@*/ struct availlist *prev; int avail; int current; int node; int max; char address[100]; /*@null@*/ /*@owned@*/ struct availlist *next; }; The list is: /*@null@*/ /*@owned@*/ static struct availlist *masteravaillist ; static /*@null@*/ struct availlist *addcounter(int node) { struct availlist *tmplist, *newlist ; newlist=zalloc(sizeof(struct availlist)) ; if(newlist == NULL) { error_log("Out of memory in addcounter(lobbys)\n") ; return(NULL) ; } LLLinkToList(newlist, tmplist, masteravaillist) ; tmplist->node = node ; tmplist->avail = 0 ; tmplist->current = 0 ; tmplist->max = 0 ; *tmplist->address = '\0' ; return(newlist) ; } -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing. From gmack at innerfire.net Sun Jan 29 10:42:22 2006 From: gmack at innerfire.net (Gerhard Mack) Date: Wed Mar 22 17:11:24 2006 Subject: please ignore Re: [splint-discuss] not sure how to annotate items returned from a linked list In-Reply-To: References: Message-ID: Ignore this.. It seems it was a problem with the flags I was sending splint. Gerhard On Sun, 29 Jan 2006, Gerhard Mack wrote: > Date: Sun, 29 Jan 2006 08:06:06 -0500 (EST) > From: Gerhard Mack > Reply-To: Discussions about the Splint annotation-assisted static analysis > project > To: splint-discuss@ares.cs.Virginia.EDU > Subject: [splint-discuss] not sure how to annotate items returned from a > linked list > > hello, > > I'm just starting to use splint on a project I'm working on and I can't > quite figgure out how to annotate a function that returns a list item. > > Any help would be appreciated. > > Right now I get: > > src/lobbys.c:97:19: Function returns with global masteravaillist > referencing released storage > src/lobbys.c:97:8: Storage masteravaillist released > > the struct is defined as: > /*@abstract@*/ struct availlist { > /*@null@*/ /*@dependent@*/ struct availlist *prev; > int avail; > int current; > int node; > int max; > char address[100]; > /*@null@*/ /*@owned@*/ struct availlist *next; > }; > > The list is: > /*@null@*/ /*@owned@*/ static struct availlist *masteravaillist ; > > static /*@null@*/ struct availlist *addcounter(int node) > { > struct availlist *tmplist, *newlist ; > > newlist=zalloc(sizeof(struct availlist)) ; > > if(newlist == NULL) { > error_log("Out of memory in addcounter(lobbys)\n") ; > return(NULL) ; > } > > LLLinkToList(newlist, tmplist, masteravaillist) ; > > tmplist->node = node ; > tmplist->avail = 0 ; > tmplist->current = 0 ; > tmplist->max = 0 ; > *tmplist->address = '\0' ; > > return(newlist) ; > } > > -- > Gerhard Mack > > gmack@innerfire.net > > <>< As a computer I find your faith in technology amusing. > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing.