From brian.thorpe at tait.co.nz Wed Jan 8 23:07:09 2003 From: brian.thorpe at tait.co.nz (Brian Thorpe) Date: Wed Mar 22 17:09:57 2006 Subject: [splint-discuss] What are splint's command line options Message-ID: <3E1CF56D.FC9CBF50@tait.co.nz> Hi, I'm a new user of Splint, have downloaded the code and scanned through the manual, but can't find anywhere that describes the splint's command line syntax. It appears that I can specify multiple source file names, but when I do I get a change in the warning messages generated. Have I missed this in the documentation ? Also is it possible to specify the files to be checked from within a config file instead of on the command line itself (as can be done for the flags) ? Thanks, Brian Thorpe. From list_ob at gmx.net Thu Jan 9 05:13:28 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions Message-ID: <3E1D5958.31823.A46211@localhost> Hello All, in the archives I found two threads about problems with proprietary extensions used by common compilers for embedded system. Common sources of problems are: nonstandard modifiers, possibly starting with @, e.g. @interrupt void uart(void) char PORTA @0x12; and assembler blocks (#pragma asm/endasm) which are really bad for the parser. I know how to hide these constucts from Splint but I would really dislike it (see below). Are there any plans to extend the parser to be able to process (ignore) these constructs? It should at least be possible to disable/enable the parser by some simple string matching rule to exclude assembler blocks and to ignore @-modifiers. I don't want to start a religious war about extensions and ISO/IEC 9899:1999 compliance: I know that compiler manufacturers could implement the extensions in a compliant way, but why should I bother? With "variables" at fixed addresses or assembler blocks, the program part is not portable anyway. I could put assembler portions in separate files, but for interaction with the C parts, I had to posion the symbol table with stuff I don't like to make global. And although a #pragma placethisvariableatsomeaddress would be C99 compliant, I prefer to write a _one line_ nonstandard @address statement. The (*(Type *)(Address) has also diadvantages. Either it doesn't yield a symbolic value in the debugger or I have to tell the compiler separately whether it's in a short addressing range. Therefore I use these extensions without scruple. I concentrate them in some hardware specific files. I agree to name it "not really C", nevertheless I would like to lint them. Oliver From evans at cs.virginia.edu Thu Jan 9 07:20:51 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] What are splint's command line options In-Reply-To: <3E1CF56D.FC9CBF50@tait.co.nz> Message-ID: Hi Brian, See www.splint.org for splint documentation. http://www.splint.org/manual/html/sec1.html gives an overview of Splint operation, and http://www.splint.org/manual/html/appB.html describes all the command line options. --- Dave On Thu, 9 Jan 2003, Brian Thorpe wrote: > Hi, > I'm a new user of Splint, have downloaded the code and scanned through the manual, > but can't find anywhere that describes the splint's command line syntax. It appears > that I can specify multiple source file names, but when I do I get a change in the > warning messages generated. Have I missed this in the documentation ? > Also is it possible to specify the files to be checked from within a config file > instead of on the command line itself (as can be done for the flags) ? > Thanks, > Brian Thorpe. > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From evans at cs.virginia.edu Thu Jan 9 07:24:45 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions In-Reply-To: <3E1D5958.31823.A46211@localhost> Message-ID: Hi Oliver, We don't have any plans to expect Splint to support proprietary language extensions, but if anyone sends us code patches to support a particular compilers extensions (in a way that doesn't impact normal executions) we'd be happy to incorporate them. Best, --- Dave On Thu, 9 Jan 2003, Oliver Betz wrote: > Hello All, > > in the archives I found two threads about problems with proprietary > extensions used by common compilers for embedded system. > > Common sources of problems are: > > nonstandard modifiers, possibly starting with @, e.g. > @interrupt void uart(void) > char PORTA @0x12; > > and assembler blocks (#pragma asm/endasm) which are really bad for > the parser. > > I know how to hide these constucts from Splint but I would really > dislike it (see below). > > Are there any plans to extend the parser to be able to process > (ignore) these constructs? It should at least be possible to > disable/enable the parser by some simple string matching rule to > exclude assembler blocks and to ignore @-modifiers. > > I don't want to start a religious war about extensions and ISO/IEC > 9899:1999 compliance: I know that compiler manufacturers could > implement the extensions in a compliant way, but why should I bother? > > With "variables" at fixed addresses or assembler blocks, the program > part is not portable anyway. > > I could put assembler portions in separate files, but for interaction > with the C parts, I had to posion the symbol table with stuff I don't > like to make global. > > And although a #pragma placethisvariableatsomeaddress would be C99 > compliant, I prefer to write a _one line_ nonstandard @address > statement. The (*(Type *)(Address) has also diadvantages. Either it > doesn't yield a symbolic value in the debugger or I have to tell the > compiler separately whether it's in a short addressing range. > > Therefore I use these extensions without scruple. I concentrate them > in some hardware specific files. I agree to name it "not really C", > nevertheless I would like to lint them. > > Oliver > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From list_ob at gmx.net Thu Jan 9 15:19:17 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Re: Tolerance for compiler extensions In-Reply-To: References: <3E1D9D08.24101.1ACD6F7@localhost> Message-ID: <3E1DE755.9709.7B182B@localhost> David Evans wrote: > If its just filtering you want, why not just pre-process the input with > some filtering program like awk? 1. How can I tell Splint to filter '#include'd files through awk? 2. I'm not familiar with awk. Therefore I buy PC-Lint and do things I can do much more efficient. As I wrote: it's meant as a suggestion to enable Splint to be used with common (sic!) embedded compilers. It's not for my personal benefit. (I forgot to send my last message to the list, therefore I quote it here) > > I didn't think about support for "particular" features/compilers but > > wanted to suggest a simple but versatile filtering method in the > > parser, preferably based on regular expressions. > > > > With such filtering it would be easy to ignore some expressions (e.g. > > certain modifiers) or to stop processing (except for line number > > counting) after a "#pragma asm" and continue after a "#pragma > > endasm". > > > > Only a suggestion for a general improvement, I do not really depend > > on it since I likely will use PC-Lint. Oliver -- Oliver Betz Geisenbrunner Strasse 84 81475 Muenchen From PSchmidt at omnimn.com Mon Jan 13 14:31:06 2003 From: PSchmidt at omnimn.com (Phil Schmidt) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] RE: Handling special syntax used by embedded C compilers Message-ID: Hey folks! I wanted to bring up this old thread again. I've been working with SPLint lately, and I'm still having problems with special non-ANSI syntax. I'm wondering if anyone can offer any practical solutions to handle the two types of constructs I described before. My particular concern is the @ , and the #asm ... #endasm. Thanks! Phil Schmidt Omni Engineering Services, Inc. 1510 E. Sanborn St. P.O. Box 132 Winona, MN 55987 Phone: (507) 454-5293 x126 FAX: (507) 453-0922 e-mail: pschmidt@omnimn.com Web: http://www.omniminnesota.com > -----Original Message----- > From: Phil Schmidt > Sent: Friday, July 20, 2001 1:36 PM > To: 'lclint-interest@virginia.edu' > Subject: Handling special syntax used by embedded C compilers > > Is it possible to configure LCLint to recognize special syntactical > constructs that are used by C compilers for small, embedded micros? > > > > For example, the following line specifies that temp_STATUS is to be > located at address 0x0023. > ------------------------------------------ > char temp_STATUS @ 0x23; > ------------------------------------------ > > > > This construct designates a function as being an interrupt service > routine, signalling the compiler to generate different function entry and > exit code (like an "iret" instruction instead of a "ret" instruction): > ------------------------------------------ > interrupt void SomeISR() > { > .... > }; > ------------------------------------------ > > > > Also, inline assembly is often encountered: > ------------------------------------------ > #asm > org 4 > movwf temp_WREG ; goes to 0x20 or 0xA0 0004h > swapf STATUS,W ; 0005h > clrf STATUS ; 0006h > movwf temp_STATUS ; Save STATUS 0007h > movf PCLATH,W ; 0008h > movwf temp_PCLATH ; Save PCLATH 0009h > clrf PCLATH ; Clear PCLATH 000Ah > #endasm > ------------------------------------------ > > > In every case I can think of at the moment, the modified syntax can be > dealt with by simply ignoring the special text. Sure, I could create a > pre-pre-processor to strip out the special stuff, but there's got to be an > easier way.....? > > > Phil Schmidt > Omni Engineering Services, Inc. > 1510 E. Sanborn St. > P.O. Box 132 > Winona, MN 55987 > Phone: (507) 454-5293 x126 > FAX: (507) 453-0922 > e-mail: pschmidt@omnimn.com > Web: http://www.omniminnesota.com > From brian.thorpe at tait.co.nz Mon Jan 13 20:29:36 2003 From: brian.thorpe at tait.co.nz (Brian Thorpe) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Generation of library files Message-ID: <3E236800.2E779BA5@tait.co.nz> Hi, I'm still a splint novice, and currently have the following queries, would be grateful for some help: * We have a global header file (included into all C source files), which has typedefs for int8_t, uint8_t, uint32_t, etc, as these are not provided by our compiler. These typedefs seem to be defined in splint's ansi.h and standard.h libray header files, and are in ansi.lcd, standard.lcd, library.lcd files. When running splint with checking mode set to standard, I get splint warning messages for our definitions. I'm confused about which libraries are actually being used when I run splint, I think I would like to remove references to them from the splint files and that might remove the warnings I get. Can anyone give a clear description of all these libraries, how they are generated, and under what circumstances they are used ? For example, the manual refers to a comamnd line option "-dump library" to generate library.lcd, but does this flag need to be used when I'm doing a *.c parse, or can it be done standalone, and what's the difference if any to the generated file ? And if I use the -load library command line option, does that override the normal library file loading, or is it additional ? (As a further complication, I tried using splint to dump the standard ansi library as specified in section 14.2.1 and splint generated an internal error which I've just reported). * We have code which can be represented in much simplified form as follows: extern int Var1; const struct { int * pVar; } Var2 = { &Var1 }; This generates the following splint warning: " Immediate address &Var1 used as initial value for implicitly only: Var2.pVar = &Var1 An immediate address (result of & operator) is transferred inconsistently. (Use -immediatetrans to inhibit warning)". Can anyone explain this, and where in the splint manual I can reference the cause / solution ? At the moment we do not want to start adding splint annotations to our code and are aiming to get a warning free parse using the weak flag, and are willing to manually check warnings that occur when we parse in standard mode (but would prefer there to be not too many). Brian Thorpe Tait Electronics, Christchurch, New Zealand. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20030114/ed1e295b/attachment.htm From list_ob at gmx.net Tue Jan 14 02:55:16 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions In-Reply-To: <200301140030.h0E0UgHG382322@atlas.otago.ac.nz> Message-ID: <3E23D074.5280.168F14@localhost> Richard A. O'Keefe wrote: [big snip] > "Oliver Betz" > I know how to hide these constucts from Splint but I would really > dislike it (see below). > > I know using macros this way is a little clumsier than writing directly, > but it's not _much_ clumsier, so why would anyone 'really dislike it'? One reason is "existing code". Not only my own, but also from the compiler manufacturer (#include). In my last posting, I already asked David Evans "how to filter '#include'd files through awk" or anything else. This might be a problem. > This has to be a _lot_ less work than hacking on Splint, and since there > is no standard for non-standard C, Splint would have to be hacked in a I disagree. "non-standard" is no explanation for a complicated hack. I already made a suggestion how to do it in a "simple" (?) way: | I didn't think about support for "particular" features/compilers but | wanted to suggest a simple but versatile filtering method in the | parser, preferably based on regular expressions. | | With such filtering it would be easy to ignore some expressions (e.g. | certain modifiers) or to stop processing (except for line number | counting) after a "#pragma asm" and continue after a "#pragma | endasm". If the above explanation is not 100% clear, please ask. My English might be a bit strange since I'm not a native speaker. Oliver From ok at cs.otago.ac.nz Mon Jan 13 19:30:42 2003 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions Message-ID: <200301140030.h0E0UgHG382322@atlas.otago.ac.nz> "Oliver Betz" wants to use Splint to check stuff in a language resembling C. Two specific examples are given: 1. nonstandard modifiers, possibly starting with @, e.g. @interrupt void uart(void) char PORTA @0x12; This can be handled using the preprocessor. normal/macros.h /* Macros for normal compilation */ #define INTERRUPT @interrupt #define AT(addr) @addr splint/macros.h /* Macros for checking with splint */ #define INTERRUPT #define AT(addr) The examples then become #include "macros.h" ... INTERRUPT void uart(void) char PORTA AT(0x12); The normal/macros.h file is placed where the compiler will find it, and a shell script/batch file is written for splint, which script tells splint to look first in the directory where splint/macros.h was placed. 2. and assembler blocks (#pragma asm/endasm) which are really bad for the parser. That is seriously evil; #pragma isn't supposed to be used that way. Splint will be unable to check data flow that occurs inside such blocks. We can still hack this using the macro approach. I'm assuming here that the assembly code uses C lexical structure. normal/macros.h ... #define USES(x) #define SETS(x) #define C0DE(x) x #define C1DE(x,y) x,y #define C2DE(x,y,z) x,y,z splint/macros.h ... #define USES(x) (void)(x); #define SETS(x) ((x) = 0); #define C0DE(x) #define C1DE(x,y) #define C2DE(x,y,z) Now you can write void junk(void) { #pragma asm USES(x) USES(y) SETS(z) C1DE(movl x, EAX) C1DE(addl y, EAX) C1DE(movl EAX, z) #pragma endasm "Oliver Betz" I know how to hide these constucts from Splint but I would really dislike it (see below). I know using macros this way is a little clumsier than writing directly, but it's not _much_ clumsier, so why would anyone 'really dislike it'? This has to be a _lot_ less work than hacking on Splint, and since there is no standard for non-standard C, Splint would have to be hacked in a large number of incompatible ways. (Of the three C compilers I'm using on this machine, one doesn't handle asm insertions at all and the other two do it very differently, and neither of them uses #pragma. Another C compiler on another machine I have here does it in a third way. And on another machine in this room, the C compiler does it a fourth way...) From ok at cs.otago.ac.nz Tue Jan 14 21:19:53 2003 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions Message-ID: <200301150219.h0F2JrJZ383138@atlas.otago.ac.nz> "Oliver Betz" wrote: (> quotes are from me) > I know using macros this way is a little clumsier than writing directly, > but it's not _much_ clumsier, so why would anyone 'really dislike it'? One reason is "existing code". Not only my own, but also from the compiler manufacturer (#include). That really isn't a very good reason. For example, GCC has this problem. What happens when you install GCC? You get a whole fresh *edited* copy of the system #includes. First off, just which non-standard constructs do in fact appear in the system headers? (I was going to say that it would be very poor system design that put assembly code inclusions into headers, but then remembered some of the Macintosh C compilers I've had to deal with.) Second, just how *much* code are we talking about in the system headers? I strongly suspect that creating a mirror of the vendor's headers with the appropriate macros inserted will be MUCH easier than patching splint. In my last posting, I already asked David Evans "how to filter '#include'd files through awk" or anything else. This might be a problem. I don't quite understand what you are asking for here, but my suggestion is that _every_ source file that you want the compiler to see and that you want splint to see should be modified to use the appropriate macros. This doesn't involve any run-time filtering at all, which makes life a lot easier. It is actually quite easy to write an include processor in AWK. Here's one: #!/usr/ucb/awk -f #File: include.awk /^#include[ \t]+"/ { x = $0 sub(/^#include[ \t]+"/, "", x) sub(/"[ \t]+$/, "", x) system("/usr/ucb/awk -f include.awk '" x "'") next } { print } Of course, the trick was the bit where I said "AN include processor", not "an include processor that does everything a C include processor has to". C allows things like #ifdef FOO #define BAR "foo/bar.h" #else #define BAR "bar.h" #endif ?? /\ * comment *\ / include BAR Coping with directory lists pales into insignificance compared with this. There's really only one way to do C inclusion right, and that's to have a full C preprocessor. Having said that, you don't in fact have to deal with arbitrary code, you just have to deal with the code YOU write (which can use the nice macros from day 1) and the external code you use (which should not be arbitrarily nasty, so that it should be possible to write a few fairly simple Python, PERL, AWK, or even sed scripts to make the changes. For example, suppose we want to convert @interrupt -> INTERRUPT @; -> AT(); Here's an (untested) AWK script for that: /@interrupt/ { sub(/@interrupt/, "INTERRUPT ") } $NF ~ /^@[0-7a-fA-FxX]+;/ { $NF = "AT(" substr($NF, 2, length($NF)-2) ")" } print Remember, I am NOT suggesting a recursive or run-time translation here; I am suggesting filtering each file _once_ into a mirror treee. > This has to be a _lot_ less work than hacking on Splint, and since there > is no standard for non-standard C, Splint would have to be hacked in a I disagree. "non-standard" is no explanation for a complicated hack. No, the hack I'm suggesting is the simple one. Simple as in "takes MUCH less time to implement, takes MUCH less code to implement, is MUCH easier to test, is GUARANTEED not to break anything in splint, is MUCH easier to understand and use." I already made a suggestion how to do it in a "simple" (?) way: No, you've made an extremely vague suggestion for something which seems likely to be extremely complicated. | I didn't think about support for "particular" features/compilers but | wanted to suggest a simple but versatile filtering method in the | parser, preferably based on regular expressions. You have expressed a wish that a simple solution of such a kind should exist. You have not yet suggested how it could be done simply. At *some* point *someone* is going to have to write some compiler-specific transformation rules that say how to handle the quirks of a particular compiler. (As noted before, compilers vary a _LOT_ in the extensions they offer.) Before anyone considers making even the slightest change to splint to support such rules, we need to have *some* idea of what the rules should look like. In fact, we should have TESTED rules. | With such filtering it would be easy to ignore some expressions (e.g. | certain modifiers) or to stop processing (except for line number | counting) after a "#pragma asm" and continue after a "#pragma | endasm". It's easy to make such an assertion. It is less easy to justify it. If the above explanation is not 100% clear, please ask. My English might be a bit strange since I'm not a native speaker. The English is not a problem. Basically, you are asking that someone should do a lot of work to implement a feature you want, without giving a sufficiently precise specification of what the feature should _do_ to make it possible for anyone to do so. The first thing that must be done is for YOU to design and test the rules you want using the approach I've suggested. (1) Use the programming language of your choice to implement a NON-RECURSIVE filter. I've given two rules in AWK. You may find that Perl's more powerful regular expressions make it easier to do what you want in Perl. (2) Make a directory tree that mirrors the structure of the directory tree you want to work with. (2a) Part of this consists of system headers and other imported code. This will be the same for every one of your programs, so you might as well do it just once. (2b) Part of this consists of your code. If you are willing to use macros as I have suggested, this will dramatically simplify your building process, because you won't _have_ to filter your code. Otherwise it can be filtered and you will have to tell your building process how/when to do this. (3) The vendor's compiler should be able to work DIRECTLY with the filtered filters. This gives you an added consistency check. (4) Splint *without modifications* should be able to work DIRECTLY with the filtered files. When you have this working, and it really should NOT be hard, you won't actually _need_ any changes to Splint. Should you still think that changes to Splint are appropriate, you will THEN (and only then) be in a position to say exactly what kind of rules you need. Of course, it _still_ won't be a good idea to make any changes to Splint until several rule sets for several different non-standard compilers have been developed. "Non-standard" means they could do anything. As I've noted with respect to assembly code insertions, there are _lots_ of different ways, and hacking #pragma asm/endasm would leave me staring at at least five other assembly inclusion methods needing rules differing in kind, not merely in detail. As I noted before, simply *skipping* assembly code means you lose a good deal of the power of Splint. Splint can track data flow through normal C code. It would be unreasonable to expect Splint to be able to process several dozen kinds of assembly code, especially as some "assembly" inclusions aren't. But it WOULD be worth while having assembly inclusions annotated with the data flow that you think is there so that Splint can check that for consistency with the rest of the program and specifications, and one merit of the macro approach is precisely that it requires someone using it to at least look once at every assembly fragment, which might just encourage them to annotate it... I am aware of one C preprocessor which tries to be extension-friendly. That's "app" from AT&T. (Available free in binary form for non-commercial use.) However, there are fairly severe limitations on what it can handle; it can be taught to ignore various tokens and not much else. From list_ob at gmx.net Wed Jan 15 04:03:57 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions In-Reply-To: <200301150219.h0F2JrJZ383138@atlas.otago.ac.nz> Message-ID: <3E25320D.12469.7A1ADC@localhost> BTW: I prefer lists configured to add a Reply-To: to the list address. Maybe somebody wants to change this. Richard A. O'Keefe wrote: Your solution: > Remember, I am NOT suggesting a recursive or run-time translation > here; I am suggesting filtering each file _once_ into a mirror treee. ...needs another workaround to open the right file in the editor from Splint's error message. Needs "make" to avoid processing of all files. I expect more problems. For me that's complicated and ugly, I would prefer to change the code to hide the extensions in '#define's. More important: you assumend that _I want_ these extensions: > You have expressed a wish that a simple solution of such a kind should > exist. You have not yet suggested how it could be done simply. Wrong, I didn't express any wish. > Basically, you are asking that someone should do a lot of work to I asked for nothing. > The first thing that must be done is for YOU to design and test the Also wrong, it's not "for me". I already stated that I have a better solution for _my_ needs, although it costs money. I would be completely nuts if I spend a day to make your suggestions working instead of _buying a suitable lint_. Even if I made the extensions for the public, the time probably would be wasted, because it's still ugly and complicated (not least due to my lack of experience), and therefore maybe nobody would use it. Maybe (I can't estimate) other "embedded" programmers would benefit from a more tolerant Splint, therefore I suggested a possible improvement. But it's not my intention to convince Splint programmers to do something they don't like. If somebody needs information about compiler specific extensions or how PC-Lint handles them, I certainly will help. Oliver From cbfalconer at yahoo.com Wed Jan 15 03:24:07 2003 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions References: <200301150219.h0F2JrJZ383138@atlas.otago.ac.nz> Message-ID: <3E251AA7.6CE2607A@yahoo.com> "Richard A. O'Keefe" wrote: > "Oliver Betz" wrote: > (> quotes are from me) > > > I know using macros this way is a little clumsier than > > writing directly, but it's not _much_ clumsier, so why > > would anyone 'really dislike it'? > > One reason is "existing code". Not only my own, but also > from the compiler manufacturer (#include). > ... snip ... > > You have expressed a wish that a simple solution of such a kind > should exist. You have not yet suggested how it could be done > simply. > > At *some* point *someone* is going to have to write some > compiler-specific transformation rules that say how to handle > the quirks of a particular compiler. (As noted before, compilers > vary a _LOT_ in the extensions they offer.) > > Before anyone considers making even the slightest change to > splint to support such rules, we need to have *some* idea of > what the rules should look like. In fact, we should have TESTED > rules. I have no problem with your attitude here, but in the past I have posted obviously correct snippets here that triggered false warnings from splint, and received nothing more than 'how to suppress that warning' replies. Maybe you were not monitoring the list at the time. This comment is seriously weakened by the fact that I don't have those snippets available at the moment. However the net impression was that splint was to be considered perfect, and that nobody had the slightest interest in bug reports. So I gave up such. One that I remember had to do with realloc. It was code something like: if (tmp = realloc(ptr, ...)) dosomething(); else return ptr; return tmp; where splint falsely insisted that I was leaking memory. At any rate the code in ggets.zip (see download section of my URL in sig line) triggers several of these problems. Some of the warnings are correct. The code involved is less than a hundred lines. I do not wish to decorate portable code with splint-specific pseudo comments. FYI this is with splint 3.0.1.6. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From Simon.Hosie at connexionz.co.nz Wed Jan 15 16:49:13 2003 From: Simon.Hosie at connexionz.co.nz (Simon Hosie) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions Message-ID: CBFalconer: > [...] and received nothing more than 'how to suppress that warning' > replies. > [...] However the net impression was that splint was to be considered > perfect, and that nobody had the slightest interest in bug reports. I'd like to imagine that that you got that advice not because splint is perfect, but because the solution is so hard, or so specific, that it'll take a lot of time, or too much time to bother, and most people want an immediate solution. At the same time, I am painfully aware that the world is full of people that will try to solve things as if it was their own fault much more readily than acknowledge the limitations or faults of the tools they're using. Maybe I should look at the archives and see what you're talking about. > I do not wish to decorate portable code with splint-specific > pseudo comments. FYI this is with splint 3.0.1.6. You'll always be limited by the tools you use. There are a whole bunch of safe things that C won't let you do, but you tolerate that for the benefits, and there are some more things that splint won't let you do, so you either tolerate that (for the benefits), or you negotiate with it, or you throw it out. From ok at cs.otago.ac.nz Wed Jan 15 23:29:40 2003 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions Message-ID: <200301160429.h0G4TeCO401717@atlas.otago.ac.nz> CBFalconer wrote: I have no problem with your attitude here, but in the past I have posted obviously correct snippets here that triggered false warnings from splint, and received nothing more than 'how to suppress that warning' replies. Maybe you were not monitoring the list at the time. This comment is seriously weakened by the fact that I don't have those snippets available at the moment. However the net impression was that splint was to be considered perfect, and that nobody had the slightest interest in bug reports. So I gave up such. I have been reading this list for a long time. During that time, I have frequently sent small suggestions to the list or the author, and have seen several of my suggestions adopted. I have certainly never seen anything that I could interpret as a claim or even suggestion that 'splint was to be considered perfect'. Indeed, the documentation is quite explicit that it isn't. Nobody who looks as the number of bug fixes would imagine that there was disinterest in bug reports. The only resistance I've seen to bug reports or change requests has basically been along the lines of such a change would be too HARD or would conflict with some other desirable feature or that it wasn't clear how to do it or that the problem was better addressed some other way. One that I remember had to do with realloc. It was code something like: if (tmp = realloc(ptr, ...)) dosomething(); else return ptr; return tmp; where splint falsely insisted that I was leaking memory. What happens if you rewrite it as tmp = realloc(ptr, ...); if (tmp == NULL) { tmp = ptr; } else { dosomething(); } return tmp; I do not wish to decorate portable code with splint-specific pseudo comments. FYI this is with splint 3.0.1.6. I don't see what the portability of the code has to do with not wanting to annotate it. If you don't tell splint what's supposed to be going on, it can't check that it _is_. Adding splint annotations is one way to help ensure that your code really _is_ portable. In the case of memory allocation checks, you can pretty much guarantee that splint will get them wrong without annotations. If you don't want to bother giving splint a few hints (which turn out to be quite helpful hints to humans reading the code too), then you had best ask splint not to bother making the checks. For what it's worth, I _do_ have access to a Lint that checks for some of the things that Splint does and it doesn't have Splint-like annotations to guide it. And that's why I never use that feature, because in practice it always gets them wrong. Splint is, and is intended to be, a heuristic tool for checking more-or-less portable C code. It isn't perfect, it isn't meant to be perfect, and it never _can_ be perfect. But it does have a mailing list with some fairly helpful people on it. From list_ob at gmx.net Thu Jan 16 04:41:56 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Tolerance for compiler extensions In-Reply-To: <200301150219.h0F2JrJZ383138@atlas.otago.ac.nz> Message-ID: <3E268C74.3188.8E6F78@localhost> Richard A. O'Keefe wrote: [...] > I strongly suspect that creating a mirror of the vendor's headers with [...and modify own code _once_ with awk] Sorry, I misunderstood this in my first reply and thought you wanted to make a mirror each time Splint is running. Well, as I wrote in my original posting, I know how to hide everything from Splint, with awk or something else. But I prefer not to use these constructs. "de gustibus non est disputandum" Oliver From kieron at dimetrodon.demon.co.uk Sat Jan 18 13:31:45 2003 From: kieron at dimetrodon.demon.co.uk (Kieron Dunbar) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Questions from a new user Message-ID: <3E299D91.9E6CF460@dimetrodon.demon.co.uk> I've recently tried to use splint to check for a few things, and there are a few things about it which are not clear to me. Is there a way to ask splint not to report warnings for system headers (e.g. anything included with <>)? I have no wish to modify them, so I'd prefer splint not to warn me about problems in them. This is particularly true as many of the warnings it gives are things like the following: usr/include/stdio.h:27: Name _STDIO_H is in the implementation name space Is there a simple way to disable all checks? I'm only interested in looking at one or two possible causes of error at a time, so a way of removing all error conditions more convenient than turning off each option individually would be useful. splint gives a "Dereference of possibly null pointer cal: *cal" error on the following line (where cal is an automatic pointer which is set in a separate function): if (i == 'a' && cal) (*cal) = ca; The error disappears if I change it to "if (i == 'a') if (cal) (*cal) = ca;", but I'm surprised that it appeared in the first place. -- kwaheri, Kieron From evans at cs.virginia.edu Sun Jan 19 18:19:37 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Questions from a new user In-Reply-To: <3E299D91.9E6CF460@dimetrodon.demon.co.uk> Message-ID: On Sat, 18 Jan 2003, Kieron Dunbar wrote: > I've recently tried to use splint to check for a few things, and there are a > few things about it which are not clear to me. > > Is there a way to ask splint not to report warnings for system headers (e.g. > anything included with <>)? I have no wish to modify them, so I'd prefer > splint not to warn me about problems in them. This is particularly true as > many of the warnings it gives are things like the following: > > usr/include/stdio.h:27: Name _STDIO_H is in the implementation name space > You can control splint to not report warnings in system directories based on the directory they are in (not how they are included). See splint -help sysdirerrors and splint -help sysdirs for more info. > Is there a simple way to disable all checks? I'm only interested in looking at > one or two possible causes of error at a time, so a way of removing all error > conditions more convenient than turning off each option individually would be > useful. > No, there's no way to turn off all warnings. Using -weak will turn off many warnings. We've been thinking of sensible ways of supporting what you suggest in the next version. > splint gives a "Dereference of possibly null pointer cal: *cal" error on the > following line (where cal is an automatic pointer which is set in a separate > function): > > if (i == 'a' && cal) (*cal) = ca; > > The error disappears if I change it to "if (i == 'a') if (cal) (*cal) = ca;", > but I'm surprised that it appeared in the first place. > You're right, there should be no warning here. Inside the && clause, cal isn't interpreted correctly by the analysis. If you replaced it with if (i == 'a' && cal != NULL) ... it would work. --- Dave > -- > kwaheri, Kieron > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From Jean-Michel.Audet at ca.Kontron.com Tue Jan 21 13:48:10 2003 From: Jean-Michel.Audet at ca.Kontron.com (Audet, Jean-Michel) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Using Splint with Linux Char Driver Message-ID: <5009AD9521A8D41198EE00805F85F18F037174FF@sembo111.teknor.com> - I am new to Splint In Linux.. I use splint to check micro-processor firmware in the past. Hi, I am having problem using splint to parse a char driver in linux. My linux Kernel is 2.4.18 i686 single processor. Here is my .splintrc file content #LcLint settings -larchpath /usr/share/splint/lib -lclimportdir /usr/share/splint/imports -systemdirs /usr/include:/usr/local/lib/:/usr/lib #-sys-dir-errors -sys-unrecog -weak I always get the following output: ================================ Splint 3.0.1.6 --- 26 Feb 2002 usr/include/asm/types.h:11:24: Parse Error: Suspect missing struct or union keyword: _ _signed_ _ : unsigned short int. (For help on parse error, see splint -help parseerrors.) *** Cannot continue. ================================ Thanks for your help. Jean-Michel Audet Kontron Jean-Michel.Audet@ca.kontron.com From Jean-Michel.Audet at ca.Kontron.com Tue Jan 21 13:40:52 2003 From: Jean-Michel.Audet at ca.Kontron.com (Audet, Jean-Michel) Date: Wed Mar 22 17:09:58 2006 Subject: [splint-discuss] Using Splint with Linux Char Driver Message-ID: <5009AD9521A8D41198EE00805F85F18F037174ED@sembo111.teknor.com> - I am new to Splint In Linux.. I use splint to check micro-processor firmware in the past. Hi, I am having problem using splint to parse a char driver in linux. My linux Kernel is 2.4.18 i686 single processor. Here is my .splintrc file content #LcLint settings -larchpath /usr/share/splint/lib -lclimportdir /usr/share/splint/imports -systemdirs /usr/include:/usr/local/lib/:/usr/lib #-sys-dir-errors -sys-unrecog -weak I always get the following output: ================================ Splint 3.0.1.6 --- 26 Feb 2002 usr/include/asm/types.h:11:24: Parse Error: Suspect missing struct or union keyword: _ _signed_ _ : unsigned short int. (For help on parse error, see splint -help parseerrors.) *** Cannot continue. ================================ Thanks for your help. Jean-Michel Audet Kontron Jean-Michel.Audet@ca.kontron.com From hagg.peter at kolumbus.fi Thu Jan 23 04:29:07 2003 From: hagg.peter at kolumbus.fi (Peter =?ISO-8859-1?B?SORnZw==?=) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] Errors parsing definitions Message-ID: <20030123092907.VKRU10688.fep06-app.kolumbus.fi@[193.229.5.108]> Hi, I need a little help here. I'm trying to use splint on a GNOME project of mine, unsuccessfully. There problem is like this: I try to splint code that includes the gnome libraries. This is where I run into problems, when parsing /usr/include/glib-2.0/glib/gmessages.h I get a parsing error. The exact splint output is: usr/include/glib-2.0/glib/gmessages.h:115:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:115:44: Parameter list for #define is not parseable usr/include/glib-2.0/glib/gmessages.h:118:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:118:44: Parameter list for #define is not parseable usr/include/glib-2.0/glib/gmessages.h:121:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:121:44: Parameter list for #define is not parseable usr/include/glib-2.0/glib/gmessages.h:124:44: invalid character in macro parameter name usr/include/glib-2.0/glib/gmessages.h:124:44: Parameter list for #define is not parseable Preprocessing error for file: /home/pehagg/source/gunit-0.1/lib/suite.c *** Cannot continue. make: *** [splint] Error 1 And the relevant source code (starting on line 112) looks like this: #ifdef G_HAVE_ISO_VARARGS #define g_error(...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_ERROR, \ __VA_ARGS__) #define g_message(...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_MESSAGE, \ __VA_ARGS__) #define g_critical(...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_CRITICAL, \ __VA_ARGS__) #define g_warning(...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_WARNING, \ __VA_ARGS__) I can't obviously change this code to work with splint... Any ideas what might help? - Pete - -- Peter H?gg Web Page: http://linuxdude.cjb.net ICQ# : 29623442 From evans at cs.virginia.edu Thu Jan 23 08:07:25 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] Errors parsing definitions In-Reply-To: <20030123092907.VKRU10688.fep06-app.kolumbus.fi@[193.229.5.108]> References: <20030123092907.VKRU10688.fep06-app.kolumbus.fi@[193.229.5.108]> Message-ID: Sorry, splint doesn't handle variadic macros. I'm guessing if you -UG_HAVE_ISO_VARARGS you would be able to just skip this code and avoid this problem (unless G_HAVE_ISO_VARARGS is defined earlier somewhere else). At worst, you can create a copy the problematic include files somewhere else where you can edit them, and set your splint include paths to find those files instead of the unedited ones. --- Dave On Thu, 23 Jan 2003, Peter [ISO-8859-1] H?gg wrote: > Hi, > > I need a little help here. I'm trying to use splint on a GNOME project of mine, unsuccessfully. There problem is like this: > > I try to splint code that includes the gnome libraries. This is where I run into problems, when parsing /usr/include/glib-2.0/glib/gmessages.h I get a parsing error. > > The exact splint output is: > > usr/include/glib-2.0/glib/gmessages.h:115:44: invalid character in macro parameter name > usr/include/glib-2.0/glib/gmessages.h:115:44: Parameter list for #define is not parseable > usr/include/glib-2.0/glib/gmessages.h:118:44: invalid character in macro parameter name > usr/include/glib-2.0/glib/gmessages.h:118:44: Parameter list for #define is not parseable > usr/include/glib-2.0/glib/gmessages.h:121:44: invalid character in macro parameter name > usr/include/glib-2.0/glib/gmessages.h:121:44: Parameter list for #define is not parseable > usr/include/glib-2.0/glib/gmessages.h:124:44: invalid character in macro parameter name > usr/include/glib-2.0/glib/gmessages.h:124:44: Parameter list for #define is not parseable > Preprocessing error for file: /home/pehagg/source/gunit-0.1/lib/suite.c > *** Cannot continue. > make: *** [splint] Error 1 > > And the relevant source code (starting on line 112) looks like this: > > #ifdef G_HAVE_ISO_VARARGS > #define g_error(...) g_log (G_LOG_DOMAIN, \ > G_LOG_LEVEL_ERROR, \ > __VA_ARGS__) > #define g_message(...) g_log (G_LOG_DOMAIN, \ > G_LOG_LEVEL_MESSAGE, \ > __VA_ARGS__) > #define g_critical(...) g_log (G_LOG_DOMAIN, \ > G_LOG_LEVEL_CRITICAL, \ > __VA_ARGS__) > #define g_warning(...) g_log (G_LOG_DOMAIN, \ > G_LOG_LEVEL_WARNING, \ > __VA_ARGS__) > > > I can't obviously change this code to work with splint... Any ideas what might help? > > - Pete - > > > -- > Peter H?gg > Web Page: http://linuxdude.cjb.net > ICQ# : 29623442 > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From Hakan.E.Jonsson at se.flextronics.com Thu Jan 23 10:18:15 2003 From: Hakan.E.Jonsson at se.flextronics.com (=?iso-8859-1?Q?=22H=E5kan_Jonsson=2C_E=22?=) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] strange parse error Message-ID: <8C818C0B21747240BC3D5D7B74B3EF3A0673DA@knant130.kna.flextronics.com> Hi, When trying to use splint 3.0.1.6 on a windows/intel machine I get a parse error (without further explanation) for the following line of code in basetd.h: typedef unsigned __int64 ULONG64, *PULONG64; _________________________________^__________ The parse error takes place at the ^ sign above. I changed the line to: typedef unsigned __int64 ULONG64; typedef unsigned __int64* PULONG64; but still got an error at: typedef unsigned __int64 ULONG64; _________________________________^___ typedef unsigned __int64* PULONG64; Very strange! Any ideas? Regards, H?kan Jonsson From evans at cs.virginia.edu Thu Jan 23 10:31:55 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] strange parse error In-Reply-To: <8C818C0B21747240BC3D5D7B74B3EF3A0673DA@knant130.kna.flextronics.com> References: <8C818C0B21747240BC3D5D7B74B3EF3A0673DA@knant130.kna.flextronics.com> Message-ID: The problem is __int64 is not part of the ISO C spec, but is assumed to be defined by your compiler. You can work around this by using -D__int64=int at the splint command line. --- Dave On Thu, 23 Jan 2003, [iso-8859-1] "H?kan Jonsson, E" wrote: > Hi, > > When trying to use splint 3.0.1.6 on a windows/intel machine I get a parse > error (without further explanation) for the following line of code in > basetd.h: > > typedef unsigned __int64 ULONG64, *PULONG64; > _________________________________^__________ > > The parse error takes place at the ^ sign above. > > I changed the line to: > > typedef unsigned __int64 ULONG64; > typedef unsigned __int64* PULONG64; > > but still got an error at: > typedef unsigned __int64 ULONG64; > _________________________________^___ > typedef unsigned __int64* PULONG64; > > Very strange! > > Any ideas? > > Regards, > > H?kan Jonsson > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From ok at cs.otago.ac.nz Thu Jan 23 17:16:04 2003 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] Errors parsing definitions Message-ID: <200301232216.h0NMG4C4464899@atlas.otago.ac.nz> peter.hagg@iki.fi asked about code containing #ifdef G_HAVE_ISO_VARARGS #define g_error(...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_ERROR, \ __VA_ARGS__) and other similar definitions. This feature comes from C99, and it meets an often-expressed need. We can expect to see use of this increasing in the future. It would be nice if Splint understood it. __VA_ARGS__ is a reserved name that may only appear in the definition of a varargs macro, that is, a macro whose argument list ends with ... (which is already a token in C89). Basically, it acts as if '...' were replaced by __VA_ARGS__, except that when the macro is invoked, a comma in the value for __VA_ARGS__ is just another token, NOT a separator. So it should be fairly straightforward to implement. From kieron at dimetrodon.demon.co.uk Thu Jan 23 19:40:08 2003 From: kieron at dimetrodon.demon.co.uk (Kieron Dunbar) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] Questions from a new user References: Message-ID: <3E308B68.62C4BEA8@dimetrodon.demon.co.uk> Once upon a time, David Evans wrote thus: > On Sat, 18 Jan 2003, Kieron Dunbar wrote: ... > isn't interpreted correctly by the analysis. If you replaced it with > if (i == 'a' && cal != NULL) ... > it would work. Thanks, that was all very helpful. -- kwaheri, Kieron From matt at sedeba.org.ar Thu Jan 30 14:00:21 2003 From: matt at sedeba.org.ar (Matt) Date: Wed Mar 22 17:09:59 2006 Subject: [splint-discuss] includes question.... Message-ID: <3E397645.9020706@sedeba.org.ar> Hi everybody ! Is it possible to tell to splint "do no check for other includes" ?. This is my situation. I have an script which download some projects from sourceforge's cvs and after this, runs splint. The point is that.... i.e if the source I've just downlaod needs postgress includes and I've not instaled postgress the splint says "Could not find xxxxxx.h " and stop. What I whant to do is tell the splint if some include file is missing , report it , but go on ! Is this possible (whiout hacking the splint , off course) regards matt.-