From rdbisch at ilstu.edu Thu Oct 7 08:31:02 2004 From: rdbisch at ilstu.edu (Rick Bischoff) Date: Wed Mar 22 17:10:44 2006 Subject: [splint-discuss] Confused Message-ID: Hello, I am really confused about which annotations I need for certain types of functions and variables. Problem #1 In my project, I have a series of functions that write "stuff" to a char pointer (cstring). These functions then return the pointer to where the null terminator currently is on the cstring. This allows me to, when I am ready to actually collect all of the output together, to do the following: /* Sample writing function */ char* writeSomeStuff(char* buffer) { *buffer++ = '!'; *buffer = '\0'; return buffer; } /* Sample use of said function */ void printSomeStuff() { char buf[1024]; char* temp; temp = writeSomeStuff(buf); temp = writeSomeStuff1(temp); temp = writeSomeStuff2(temp); temp = writeSomeStuff3(temp); printf("%s\n", temp); } However, if I use the "snprintf" function to write some more complicated things to the output string, splint complains: file.c:24:10: Implicitly temp storage buffer returned as implicitly only: buffer + n Temp storage (associated with a formal parameter) is transferred to a non-temporary reference. The storage may be released or new aliases created. (Use -temptrans to inhibit warning) The manual, no offense meant to the writers, is really of no help to new users. Rick Bischoff http://rickjr.org From Ralf.Wildenhues at gmx.de Sat Oct 9 03:49:21 2004 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:10:44 2006 Subject: [splint-discuss] Confused In-Reply-To: References: Message-ID: <20041009074921.GA2204@uni-bonn.de> * Rick Bischoff wrote on Thu, Oct 07, 2004 at 02:31:02PM CEST: > > Problem #1 > In my project, I have a series of functions that write "stuff" to a > char pointer (cstring). These functions then return the pointer to > where the null terminator currently is on the cstring. This allows me > to, when I am ready to actually collect all of the output together, to > do the following: > > /* Sample writing function */ > char* writeSomeStuff(char* buffer) { char* writeSomeStuff(/*@out@*/ /*@returned@*/ char* buffer); > *buffer++ = '!'; > *buffer = '\0'; > return buffer; > } > > /* Sample use of said function */ > void printSomeStuff() { > char buf[1024]; > char* temp; /*@dependent@*/ /*@temp@*/ char* temp; > temp = writeSomeStuff(buf); > temp = writeSomeStuff1(temp); > temp = writeSomeStuff2(temp); > temp = writeSomeStuff3(temp); > > printf("%s\n", temp); > } Then these don't produce any more errors. But you really should not be using an interface like this, since it makes it extremely difficult and error-prone to prevent buffer overflows. Use one that keeps track of the total size. > However, if I use the "snprintf" function to write some more > complicated things to the output string, splint complains: If above hints were not enough: Show complete example code exhibiting the problem (including the snprintf!). Regards, Ralf From RSreedharan at inautix.com Tue Oct 19 09:49:01 2004 From: RSreedharan at inautix.com (RSreedharan@inautix.com) Date: Wed Mar 22 17:10:45 2006 Subject: [splint-discuss] splint code Message-ID: Hi, For any linked list program when we assign the initial values , we are getting following warning tree->left_node = NULL; tree->max_level_left = 0; tree->right_node = NULL; tree->max_level_right = 0; Implicitly only storage tree->left_node (type struct RELATION_LIST *) not released before assignment: tree->left_node = NULL Implicitly only storage tree->right_node (type struct RELATION_LIST *) not released before assignment: tree->right_node = NULL What is wrong here ? Thanks Ratheesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20041019/03eeb37f/attachment.htm From cbfalconer at yahoo.com Wed Oct 20 01:06:26 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:45 2006 Subject: [splint-discuss] splint code References: Message-ID: <4175F252.E910D55D@yahoo.com> RSreedharan@inautix.com wrote: > > Part 1.1.1Type: Plain Text (text/plain) > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Disposed of out of hand as containing potentially dangerous html and attachments. e-mail is a text only medium. -- "I support the Red Sox and any team that beats the Yankees" "Any baby snookums can be a Yankee fan, it takes real moral fiber to be a Red Sox fan" "I listened to Toronto come back from 3:0 in '42, I plan to watch Boston come back from 3:0 in 04" From hbhalla at impulsesoft.com Fri Oct 22 19:07:24 2004 From: hbhalla at impulsesoft.com (Himanshu Bhalla) Date: Wed Mar 22 17:10:45 2006 Subject: [splint-discuss] How to specify what all .c files to be checked by splint in the input file Message-ID: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> Hi all, I am using the windows version of splint. -f option can be given through the command line to specify the various command line options for splint. I am not able to figure out ways to specify the directory path or the .c source files which should be checked by splint in the input file. I am only stuck at >splint -f splint-options.txt *.c ..\common\*.c I just want the following >splint -f splint-options.txt and I will specify the .c files to be checked in the splint-options.txt file. Can anyone suggest some answers. Thanks, Himanshu Himanshu Bhalla hbhalla@impulsesoft.com Impulsesoft Pvt. Ltd. Ph: +91.80.658 4171 Impulsesoft : Innovating Together http://www.impulsesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20041022/ef44b06b/attachment.htm From roland.illig at gmx.de Fri Oct 22 07:25:53 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed Mar 22 17:10:45 2006 Subject: [splint-discuss] How to specify what all .c files to be checked by splint in the input file In-Reply-To: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> References: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> Message-ID: <4178EE41.5070900@gmx.de> Himanshu Bhalla wrote: > Hi all, > I am using the windows version of splint. > > -f option can be given through the command line to > specify the various command line options for splint. > > I am not able to figure out ways to specify the directory path > or the .c source files which should be checked by splint in the > input file. > > I am only stuck at >splint -f splint-options.txt *.c ..\common\*.c > I just want the following >splint -f splint-options.txt > and I will specify the .c files to be checked in the splint-options.txt > file. > > Can anyone suggest some answers. > Thanks, > Himanshu Write a batch file: @echo off splint -f splint-options.txt *.c ..\common\*.c Roland From hbhalla at impulsesoft.com Fri Oct 22 21:35:24 2004 From: hbhalla at impulsesoft.com (Himanshu Bhalla) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] How to specify what all .c files to be checked by splint in the input file In-Reply-To: <4178EE41.5070900@gmx.de> References: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> <4178EE41.5070900@gmx.de> Message-ID: <6.1.0.6.0.20041022182034.02659b40@mail.impulsesoft.com> Hi, Thanks for the solution, but I still strongly feel that there should be a way to specify the source files to be checked using a command line option that can be put in the input config file. Thanks, Himanshu At 04:25 AM 10/22/2004, you wrote: >Himanshu Bhalla wrote: >>Hi all, >>I am using the windows version of splint. >>-f option can be given through the command line to >>specify the various command line options for splint. >>I am not able to figure out ways to specify the directory path >>or the .c source files which should be checked by splint in the >>input file. >>I am only stuck at >splint -f splint-options.txt *.c ..\common\*.c >>I just want the following >splint -f splint-options.txt >>and I will specify the .c files to be checked in the splint-options.txt file. >>Can anyone suggest some answers. >>Thanks, >>Himanshu > >Write a batch file: > >@echo off >splint -f splint-options.txt *.c ..\common\*.c > >Roland >_______________________________________________ >splint-discuss mailing list >splint-discuss@cs.virginia.edu >http://www.splint.org/mailman/listinfo/splint-discuss Himanshu Bhalla hbhalla@impulsesoft.com Impulsesoft Pvt. Ltd. Ph: +91.80.658 4171 Impulsesoft : Innovating Together http://www.impulsesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20041022/0369ece5/attachment.htm From evans at cs.virginia.edu Fri Oct 22 09:37:42 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] How to specify what all .c files to be checked by splint in the input file In-Reply-To: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> References: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> Message-ID: There's no way to list the files to check in the options file. If you're willing to modify the splint source code, this feature could probably be added quite easily though. Using make is a better solution for this usually, though. --- Dave On Fri, 22 Oct 2004, Himanshu Bhalla wrote: > Hi all, > I am using the windows version of splint. > > -f option can be given through the command line to > specify the various command line options for splint. > > I am not able to figure out ways to specify the directory path > or the .c source files which should be checked by splint in the > input file. > > I am only stuck at >splint -f splint-options.txt *.c ..\common\*.c > I just want the following >splint -f splint-options.txt > and I will specify the .c files to be checked in the splint-options.txt file. > > Can anyone suggest some answers. > Thanks, > Himanshu > > Himanshu Bhalla > hbhalla@impulsesoft.com > Impulsesoft Pvt. Ltd. > Ph: +91.80.658 4171 > > Impulsesoft : Innovating Together > http://www.impulsesoft.com > From cbfalconer at yahoo.com Sat Oct 23 13:22:16 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] How to specify what all .c files to be checked bysplint in the input file References: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> Message-ID: <417A9348.880511C4@yahoo.com> Himanshu Bhalla wrote: > > Part 1.1.1Type: Plain Text (text/plain) > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit FYI, all email containing either html or attachments is automatically purged here. E-mail is a pure text mechanism, and is proof against viruses etc. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From Austin_Hastings at Yahoo.com Mon Oct 25 08:05:43 2004 From: Austin_Hastings at Yahoo.com (Austin Hastings) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] How to specify what all .c files to be checked bysplint in the input file In-Reply-To: <417A9348.880511C4@yahoo.com> References: <6.1.0.6.0.20041022155707.02649b00@mail.impulsesoft.com> <417A9348.880511C4@yahoo.com> Message-ID: <417CEC17.2060108@Yahoo.com> CBFalconer wrote: >FYI, all email containing either html or attachments is >automatically purged here. E-mail is a pure text mechanism, and is proof against viruses etc. > > I dunno. Somebody sent me email about this thing called "splint", and the next thing you know there was another megabyte of executable in my path ... :) =Austin From grante at visi.com Tue Oct 26 19:28:36 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] baffled by sysdirs Message-ID: <20041026232835.GA19064@grante.dsl.visi.com> I can't figure out how to get the "sysdirs" flag to work, and I can't find any examples of pertinent command line invocation or .splintrc files in the documentation. Here's what I'm doing: ------------------------------------------------------------------------------ splint -nolib -sysdirs /opt/gnu/h8300-elf/include -I. -Iucos main.c can.c serio.c readline.c cmdhandler.c vdprintf.c 4-20in.c update.c 4-20out.c iic.c sensors.c userobjs.c eeprom.c motor.c units.c Splint 3.1.1 --- 25 Oct 2004 /usr/include/string.h:33:20: Cannot find include file stddef.h on search path: .;ucos;/usr/include;/usr/local/include Preprocessing error. (Use -preproc to inhibit warning) In file included from main.c:4 Preprocessing error for file: /home/viper/evb/ucos/main.c ------------------------------------------------------------------------------ Why is it reading string.h from /usr/include??? I told it my "sysdirs" path was /opt/gnu/h8300-elf/include, but it's it's not looking there. I also tried putting sysdirs in .splintrc, and it ignored it there as well. I verified that it was reading .splintrc by leaving off the "-" and it complained the way it should. -- Grant Edwards grante@visi.com From evans at cs.virginia.edu Tue Oct 26 19:36:13 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] baffled by sysdirs In-Reply-To: <20041026232835.GA19064@grante.dsl.visi.com> References: <20041026232835.GA19064@grante.dsl.visi.com> Message-ID: The -sysdirs flag doesn't effect the include path, just controls how checking is done for files found in those directories. For your include files to be found, you would need to use -I/opt/gnu/h8300-elf-include as well. --- Dave On Tue, 26 Oct 2004, Grant Edwards wrote: > > I can't figure out how to get the "sysdirs" flag to work, and I > can't find any examples of pertinent command line invocation or .splintrc > files in the documentation. > > Here's what I'm doing: > > ------------------------------------------------------------------------------ > splint -nolib -sysdirs /opt/gnu/h8300-elf/include -I. -Iucos main.c can.c serio.c readline.c cmdhandler.c vdprintf.c 4-20in.c update.c 4-20out.c iic.c sensors.c userobjs.c eeprom.c motor.c units.c > Splint 3.1.1 --- 25 Oct 2004 > > /usr/include/string.h:33:20: Cannot find include file stddef.h on search path: > .;ucos;/usr/include;/usr/local/include > Preprocessing error. (Use -preproc to inhibit warning) > In file included from main.c:4 > Preprocessing error for file: /home/viper/evb/ucos/main.c > ------------------------------------------------------------------------------ > > Why is it reading string.h from /usr/include??? > > I told it my "sysdirs" path was /opt/gnu/h8300-elf/include, but > it's it's not looking there. > > I also tried putting sysdirs in .splintrc, and it ignored it > there as well. I verified that it was reading .splintrc by > leaving off the "-" and it complained the way it should. > > -- > Grant Edwards > grante@visi.com > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From grante at visi.com Tue Oct 26 20:41:13 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] baffled by sysdirs In-Reply-To: References: <20041026232835.GA19064@grante.dsl.visi.com> Message-ID: <20041027004112.GA2148@grante.dsl.visi.com> On Tue, Oct 26, 2004 at 07:36:13PM -0400, David Evans wrote: > The -sysdirs flag doesn't effect the include path, just controls how > checking is done for files found in those directories. Oh. That's not what I got from reading the manual, but now that you state it plainly, I get it. [...] X.h is found in a directory that is a system directory (as set by the -sysdirs flag; the default is /usr/include), > For your include files to be found, you would need to use > -I/opt/gnu/h8300-elf-include Right, but my question was how do I get splint to _not_ look in /usr/include and /usr/local/include? I think I've found the answer: +skip-sys-headers... > > Why is it reading string.h from /usr/include??? The Manual also says something about "the system base include path (read from the include environment variable if set", but I can't find any mention of what the name of the environment variable is. -- Grant Edwards grante@visi.com From grante at visi.com Tue Oct 26 20:48:37 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] baffled by sysdirs In-Reply-To: <20041027004112.GA2148@grante.dsl.visi.com> References: <20041026232835.GA19064@grante.dsl.visi.com> <20041027004112.GA2148@grante.dsl.visi.com> Message-ID: <20041027004837.GB2148@grante.dsl.visi.com> On Tue, Oct 26, 2004 at 07:41:12PM -0500, Grant Edwards wrote: Right, but my question was how do I get splint to _not_ look in /usr/include and /usr/local/include? I think I've found the answer: +skip-sys-headers... Nope, that doesn't appear to work either: splint -nolib +skip-sys-headers -I. -Iucos main.c can.c serio.c readline.c cmdhandler.c vdprintf.c 4-20in.c update.c 4-20out.c iic.c sensors.c userobjs.c eeprom.c motor.c units.c Splint 3.1.1 --- 25 Oct 2004 vdprintf.c:11:20: Cannot find include file stdarg.h on search path: .;ucos;/usr/include;/usr/local/include /usr/include and /usr/local/include are still on the search path. I tried -skip-sys-headers, and it complains it's redundant. The search path still contains /usr/include and /usr/local/include. -- Grant Edwards grante@visi.com From evans at cs.virginia.edu Tue Oct 26 20:52:29 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] baffled by sysdirs In-Reply-To: <20041027004112.GA2148@grante.dsl.visi.com> References: <20041026232835.GA19064@grante.dsl.visi.com> <20041027004112.GA2148@grante.dsl.visi.com> Message-ID: On Tue, 26 Oct 2004, Grant Edwards wrote: > On Tue, Oct 26, 2004 at 07:36:13PM -0400, David Evans wrote: > > > The -sysdirs flag doesn't effect the include path, just controls how > > checking is done for files found in those directories. > > Oh. That's not what I got from reading the manual, but now > that you state it plainly, I get it. > > [...] X.h is found in a directory that is a system > directory (as set by the -sysdirs flag; the default is > /usr/include), > > > For your include files to be found, you would need to use > > -I/opt/gnu/h8300-elf-include > > Right, but my question was how do I get splint to _not_ look in > /usr/include and /usr/local/include? > The directories on the CPATH environment variable (INCLUDE in Windows) are added to both the include path and the sysdirs path. If you don't want these to be in the include path used by splint, you would need to unset the CPATH environment variable before running splint. > I think I've found the answer: +skip-sys-headers... > Not quite --- what skip-sys-headers does is turn off checking in the system header file (on sysders path). See http://www.splint.org/manual/html/sec14.html for details. > > > Why is it reading string.h from /usr/include??? > > The Manual also says something about "the system base include > path (read from the include environment variable if set", but I > can't find any mention of what the name of the environment > variable is. > CPATH in Unixen, INCLUDE in Windows/OS2. --- Dave > -- > Grant Edwards > grante@visi.com > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From grante at visi.com Tue Oct 26 20:55:52 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] Tell gcc to dump out include path? Message-ID: <20041027005551.GC2148@grante.dsl.visi.com> Has anybody found a way to tell gcc to print the include path, so that I can automate the generation of the -I options for splint, or at least verify that the manually generated ones are correct? Something analagous to -print-libgcc-file-name or -print-file-name=libc.a? -- Grant Edwards grante@visi.com From grante at visi.com Tue Oct 26 21:04:31 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] Re: baffled by sysdirs In-Reply-To: <20041027004112.GA2148@grante.dsl.visi.com> References: <20041026232835.GA19064@grante.dsl.visi.com> <20041027004112.GA2148@grante.dsl.visi.com> Message-ID: <20041027010430.GA2683@grante.dsl.visi.com> On Tue, Oct 26, 2004 at 07:41:13PM -0500, Grant Edwards wrote: > The Manual also says something about "the system base include > path (read from the include environment variable if set", but I > can't find any mention of what the name of the environment > variable is. Hmm. After browsing around the source code, I tried C_INCLUDE_PATH, and it made splint mad when I set it to the empty string, but setting it to a non-empty string made no apparent difference, it was still searching /usr/include and /usr/local/include. Am I the first person to try to use splint to check a program that was built without /usr/include and /usr/local/include on the include path? -- Grant From grante at visi.com Tue Oct 26 21:34:40 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] Re: baffled by sysdirs In-Reply-To: References: <20041026232835.GA19064@grante.dsl.visi.com> <20041027004112.GA2148@grante.dsl.visi.com> Message-ID: <20041027013439.GA2979@grante.dsl.visi.com> On Tue, Oct 26, 2004 at 08:52:29PM -0400, David Evans wrote: > > Right, but my question was how do I get splint to _not_ look in > > /usr/include and /usr/local/include? > > The directories on the CPATH environment variable (INCLUDE in Windows) > are added to both the include path and the sysdirs path. I guess I'm being unclear... I'm not trying to *add* things to the path, I'm trying *delete* /usr/include and /usr/local/include from the path. > If you don't want these to be in the include path used by > splint, you would need to unset the CPATH environment variable > before running splint. I don't have a CPATH variable set, and never have: $ unset CPATH; splint foo.c Splint 3.1.1 --- 25 Oct 2004 foo.c:1:25: Cannot find include file doesnotexit.h on search path: /usr/include;/usr/local/include Preprocessing error. (Use -preproc to inhibit warning) Setting CPATH to be empty doesn't help either: $ CPATH='' splint foo.c Splint 3.1.1 --- 25 Oct 2004 cstring.c:47: at source point Command Line: *** Internal Bug at cstring.c:47: llassert failed: cstring_length (s) > 0 [errno: 0] *** Please report bug to splint-bug@splint.org *** (attempting to continue, results may be incorrect) foo.c:1:25: Cannot find include file doesnotexit.h on search path: /usr/include;/usr/local/include All I'm trying to do is to have splint use the same include path that the compiler does. That path does _not_ include /usr/include or /usr/local/include. -- Grant Edwards From Ralf.Wildenhues at gmx.de Wed Oct 27 03:08:01 2004 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] Tell gcc to dump out include path? In-Reply-To: <20041027005551.GC2148@grante.dsl.visi.com> References: <20041027005551.GC2148@grante.dsl.visi.com> Message-ID: <20041027070801.GA13460@iam.uni-bonn.de> * Grant Edwards wrote on Wed, Oct 27, 2004 at 02:55:52AM CEST: > > Has anybody found a way to tell gcc to print the include path, so that I > can automate the generation of the -I options for > splint, or at least verify that the manually generated ones are > correct? echo | cpp -v Regards, Ralf From Ralf.Wildenhues at gmx.de Wed Oct 27 04:19:30 2004 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] Tell gcc to dump out include path? In-Reply-To: <20041027070801.GA13460@iam.uni-bonn.de> References: <20041027005551.GC2148@grante.dsl.visi.com> <20041027070801.GA13460@iam.uni-bonn.de> Message-ID: <20041027081930.GA4033@iam.uni-bonn.de> * Ralf Wildenhues wrote on Wed, Oct 27, 2004 at 09:08:01AM CEST: > * Grant Edwards wrote on Wed, Oct 27, 2004 at 02:55:52AM CEST: > > > > Has anybody found a way to tell gcc to print the include path, so that I > > can automate the generation of the -I options for > > splint, or at least verify that the manually generated ones are > > correct? > > echo | cpp -v Oh well, maybe you want this as well: gcc -print-file-name=include Regards, Ralf From grante at visi.com Wed Oct 27 10:45:52 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:46 2006 Subject: [splint-discuss] Re: Tell gcc to dump out include path? In-Reply-To: <20041027081930.GA4033@iam.uni-bonn.de> References: <20041027005551.GC2148@grante.dsl.visi.com> <20041027070801.GA13460@iam.uni-bonn.de> <20041027081930.GA4033@iam.uni-bonn.de> Message-ID: <20041027144550.GA31695@grante.dsl.visi.com> On Wed, Oct 27, 2004 at 10:19:30AM +0200, Ralf Wildenhues wrote: > > echo | cpp -v > > Oh well, maybe you want this as well: > gcc -print-file-name=include Brilliant! Thanks. I _swear_ I searched for all occurances of '-print' in the docs and that one wasn't there. -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 10:48:51 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Re: baffled by sysdirs In-Reply-To: <20041027013439.GA2979@grante.dsl.visi.com> References: <20041026232835.GA19064@grante.dsl.visi.com> <20041027004112.GA2148@grante.dsl.visi.com> <20041027013439.GA2979@grante.dsl.visi.com> Message-ID: <20041027144851.GB31695@grante.dsl.visi.com> > > > Right, but my question was how do I get splint to _not_ look in > > > /usr/include and /usr/local/include? > > > > The directories on the CPATH environment variable (INCLUDE in Windows) > > are added to both the include path and the sysdirs path. > > I guess I'm being unclear... > > I'm not trying to *add* things to the path, I'm trying *delete* > /usr/include and /usr/local/include from the path. My next approach is to hack config.h: /* system include directory */ #define GCC_INCLUDE_DIR "" /* alternate include directory */ #define GCC_INCLUDE_DIR2 "" Everything built, but some of the tests are failing (no surprise). Hopefully this will allow me to control the include path. -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 12:30:50 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Internal Bug in cpplib.c Message-ID: <20041027163049.GA2453@grante.dsl.visi.com> OK, I dumped out gcc's predefined macro values, and I'm trying to feed them to splint so that it can then parse the system headers. Splint generates a bunch of "Internal Bug" messages when I do that. Here's a one-line file that generates such a message: $ cat predefined.h #define __SIZE_TYPE__ unsigned int $ splint -nolib predefined.h -dump predefined Splint 3.1.1 --- 25 Oct 2004 predefined.h:1:1: *** Internal Bug at cpplib.c:2831: cpplib.c:2831: llassert failed: FALSE: Bad branch taken! [errno: 2] *** Please report bug to splint-bug@splint.org *** (attempting to continue, results may be incorrect) predefined.h:1:1: Macro __SIZE_TYPE__ already defined Finished checking --- 1 code warning How can __SIZE_TYPE__ already be defined? I told splint to parse 1 file with 1 line in it. How can that line be redefining something? -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 12:56:44 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] How to tell splint to not pre-define things? Message-ID: <20041027165643.GA2587@grante.dsl.visi.com> Splint appears to pre-define some macros: $ cat foo.h #define foo 0x12345678 $ splint -nolib foo.h -dump foo Splint 3.1.1 --- 25 Oct 2004 Finished checking --- no warnings Now, when I look at foo.lcd, it looks like there's a bunch of stuff in there that appears from nowhere: [...] *1 (Constant) ^4 5$#__LINE__ ^5 23$#__DATE__#__FILE__#__BASE_FILE__#__func__ ^9 5$#__INCLUDE_LEVEL__ ^10 23$#__VERSION__ [so far, so good] *0 (Datatype) ^11 13@c@-@0@0@0@0@59#__SIZE_TYPE__ ^12 13@c@-@0@0@0@0@60#__PTRDIFF_TYPE__ ^13 13@c@-@0@0@0@0@61#__WCHAR_TYPE__ [Where did those come from? Splint comlains if I try to define those, yet splint has no way of knowing what they're supposed to be.] *1 (Constant) ^14 23$#__USER_LABEL_PREFIX__#__REGISTER_PREFIX__#__TIME__ ^17 5$#S_SPLINT_S#__LCLINT__#__i686 [OK, I can see where S_SPLINT and __LCLINT__ might need to be defined, but why the rest? Why is __i686 defined? My architecture is H8/300H, so defining __i686 is just plain wrong.] *3 (Variable) ^20 0|@11|^#foo [There's the one that _is_ supposed to be here.] ^21 0|@1|^#stdin#stdout [My program's environment doesn't have stdin and stdout.] -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 12:10:20 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] How to predefined a set of macros? Message-ID: <20041027161019.GA2355@grante.dsl.visi.com> How do you tell splint what macros have "pre-defined" values? The -D option does what I want, but it's a bit cumbersome to put 50-100 -D options on the command line. Is there a way to "pre-load" macro definitions from a file? What I'm trying to do is get the output of "gcc -E -Wp,-dM" into splint so that when system include files are parsed splint doesn't choke because it's lacking the "pre-defined" gcc macros upon which the system files depend. -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 13:51:09 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Re: How to tell splint to not pre-define things? In-Reply-To: <20041027165643.GA2587@grante.dsl.visi.com> References: <20041027165643.GA2587@grante.dsl.visi.com> Message-ID: <20041027175108.GA7386@grante.dsl.visi.com> On Wed, Oct 27, 2004 at 11:56:44AM -0500, Grant Edwards wrote: > [Where did those come from? Splint comlains if I try to define > those, yet splint has no way of knowing what they're supposed > to be.] > > *1 (Constant) > ^14 23$#__USER_LABEL_PREFIX__#__REGISTER_PREFIX__#__TIME__ > ^17 5$#S_SPLINT_S#__LCLINT__#__i686 > > [OK, I can see where S_SPLINT and __LCLINT__ might need to be > defined, but why the rest? Why is __i686 defined? My > architecture is H8/300H, so defining __i686 is just plain > wrong.] I tried rebuilding after doing configure --target=h8300-elf, but that doesn't seem to make any difference. Splint still predefines __i686 and a bunch of other unwanted stuff. I'm stumped. Is splint hard-wired for native-only use? -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 14:37:06 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Manual corrections Message-ID: <20041027183705.GA15287@grante.dsl.visi.com> Manual in section 14.1: "In order to check calls to library functions, Splint uses an annotated standard library. This contains more information about function interfaces then is available in the system header files" Should probably read "than is available". "When checking source code, Splint does include system headers corresponding to files in the library, but instead uses the library description of the standard library." Should that read "Splint does *not* include system headers"? -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 14:59:56 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Re: How to tell splint to not pre-define things? In-Reply-To: <20041027175108.GA7386@grante.dsl.visi.com> References: <20041027165643.GA2587@grante.dsl.visi.com> <20041027175108.GA7386@grante.dsl.visi.com> Message-ID: <20041027185955.GA15810@grante.dsl.visi.com> On Wed, Oct 27, 2004 at 12:51:09PM -0500, Grant Edwards wrote: >> [Where did those come from? Splint comlains if I try to define >> those, yet splint has no way of knowing what they're supposed >> to be.] >> >> *1 (Constant) >> ^14 23$#__USER_LABEL_PREFIX__#__REGISTER_PREFIX__#__TIME__ >> ^17 5$#S_SPLINT_S#__LCLINT__#__i686 >> >> [OK, I can see where S_SPLINT and __LCLINT__ might need to be >> defined, but why the rest? Why is __i686 defined? My >> architecture is H8/300H, so defining __i686 is just plain >> wrong.] > > I tried rebuilding after doing configure --target=h8300-elf, > but that doesn't seem to make any difference. Splint still > predefines __i686 and a bunch of other unwanted stuff. Doh! I wasn't running the correct splint binary. Now splint pre-defines __h8300. That's still undesirable behavior, but it's a little less wrong than defining __i686. The correct macro to define is either __H8300__ or __H8300H__ depending on which processor is being used. Is there some way I can edit a library file to remove the incorrectly pre-defined stuff, so that I can then load that library file, and end up with the same set of macros defined that I do when I compile using gcc? The other thing I'm going to try is to hack cpplib.c and just comment out the lines that incorrectly pre-define stuff. The ones I care about most are the processor type macro and __SIZE_TYPE__ and __PTRDIFF_TYPE__. The values of those macros depend on which processor is being used: __SIZE_TYPE__ could be either "long unsigned int" or "unsigned int" __PTRDIFF_TYPE__ could be either "long int" or "int". -- Grant Edwards grante@visi.com From Ralf.Wildenhues at gmx.de Wed Oct 27 16:04:46 2004 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] How to predefined a set of macros? In-Reply-To: <20041027161019.GA2355@grante.dsl.visi.com> References: <20041027161019.GA2355@grante.dsl.visi.com> Message-ID: <20041027200446.GA6356@uni-bonn.de> * Grant Edwards wrote on Wed, Oct 27, 2004 at 06:10:20PM CEST: > > How do you tell splint what macros have "pre-defined" values? > > The -D option does what I want, but it's a bit cumbersome to > put 50-100 -D options on the command line. Is there a way to > "pre-load" macro definitions from a file? Use ~/.splintrc or ./.splintrc, or _splintrc on win32. > What I'm trying to do is get the output of "gcc -E -Wp,-dM" > into splint so that when system include files are parsed splint > doesn't choke because it's lacking the "pre-defined" gcc macros > upon which the system files depend. What are you really trying to achieve? Your questions sound to me like you want to check system (or other installed) headers. Or need them to be able to check your code. I've found that the wrong way to use splint. Rather, let splint have a different set of headers and make them as clean as possible, add a few annotations where helpful. Regards, Ralf From grante at visi.com Wed Oct 27 17:27:01 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Re: How to predefined a set of macros? In-Reply-To: <20041027200446.GA6356@uni-bonn.de> References: <20041027161019.GA2355@grante.dsl.visi.com> <20041027200446.GA6356@uni-bonn.de> Message-ID: <20041027212700.GA27405@grante.dsl.visi.com> > > The -D option does what I want, but it's a bit cumbersome to > > put 50-100 -D options on the command line. Is there a way to > > "pre-load" macro definitions from a file? > > Use ~/.splintrc or ./.splintrc, or _splintrc on win32. > > > What I'm trying to do is get the output of "gcc -E -Wp,-dM" > > into splint so that when system include files are parsed splint > > doesn't choke because it's lacking the "pre-defined" gcc macros > > upon which the system files depend. > > What are you really trying to achieve? I want to check my code using the same set of headers that will be used to compile it. > Your questions sound to me like you want to check system (or > other installed) headers. Sure, why not? Errors in those headers will generate code that's just as incorrect as errors in anything else. Besides, it's compatibility of my code with those headers that actually matters. > Or need them to be able to check your code. Why isn't checking the same set of files you're handing to the compiler a good idea? > I've found that the wrong way to use splint. Rather, let > splint have a different set of headers Why would I want to write a second set of system headers when I've already got a set? > and make them as clean as possible, add a few annotations > where helpful. If you're going that direction, why not a completely different set of C source files? ;) -- Grant Edwards grante@visi.com From grante at visi.com Wed Oct 27 17:30:49 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Bogus warnings when assigning literals to uint8_t Message-ID: <20041027213048.GA27550@grante.dsl.visi.com> uint8_t n; void foo(void) { n = 5; } That generates a warning because the literal '5' is an 'int', and it's being assigned to a 'uint8_t' lvalue. I don't understand how that could possibly be the source of an error. If the literal value didn't _fit_ in a uint8_t I can understand why there should be a warning, but what's wrong with assigning values that will fit? I _do_ want a warning for the code below, so considering all integral data types equivalent is not an option: int i; uint8_t n; void foo (void) { n = i; } The previously posted work-around is to obfuscate the code by using a char constant: n = '\0x05'; /* That would be'\005' for you PDP-11 types. */ That eliminates the warning, but I refuse on the grounds that it's horrible style. It makes it look like 'n' is supposed to be used as a character (e.g ASCII ENQ) rather than an 8-bit wide unsigned integer that's one more than 4 and one less than 6. I could pepper my code with (uint8_t) typecasts in front of all the literals destined for an 8-bit lvalue, but that makes the code even more unreadable than the character option. I'm starting to get the feeling that people who aren't writing native C apps for 32-bit targets just aren't welcome... -- Grant Edwards grante@visi.com From terry-splint at tenberry.com Wed Oct 27 18:23:16 2004 From: terry-splint at tenberry.com (Terry Colligan) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Bogus warnings when assigning literals to uint8_t In-Reply-To: <20041027213048.GA27550@grante.dsl.visi.com> References: <20041027213048.GA27550@grante.dsl.visi.com> Message-ID: <200410271523.16649.terry-splint@tenberry.com> On Wednesday 27 October 2004 02:30 pm, Grant Edwards wrote: > > uint8_t n; > > void foo(void) > { > n = 5; > } > > That generates a warning because the literal '5' is an 'int', > and it's being assigned to a 'uint8_t' lvalue. I don't > understand how that could possibly be the source of an error. > > If the literal value didn't _fit_ in a uint8_t I can understand > why there should be a warning, but what's wrong with assigning > values that will fit? I agree with Grant in every case here. In fact, we stopped using splint on our project exactly because of this problem. It's particularly annoying when the constant is 0. Using character literals with escapes satisfies splint, but I also object to what it does to our code's readability. > I _do_ want a warning for the code below, so considering all > integral data types equivalent is not an option: > > int i; > uint8_t n; > > void foo (void) > { > n = i; > } I agree, and would also expect a warning if the constant were too large to safely fit in the variable. > I could pepper my code with (uint8_t) typecasts in front of all > the literals destined for an 8-bit lvalue, but that makes the > code even more unreadable than the character option. Even worse, the cast hides real errors. Consider, for example, the following, derived from Grant's first example with the literal 5 changed to 256. uint8_t n; void foo(void) { n = (uint8_t) 256; } > I'm starting to get the feeling that people who aren't writing > native C apps for 32-bit targets just aren't welcome... > -- Terry Terry Colligan mailto:terry-splint@tenberry.com Tenberry Software, Inc. http://www.tenberry.com info@tenberry.com phone 1.480.767.8868 fax 1.480.767.8709 From grante at visi.com Wed Oct 27 18:40:38 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:47 2006 Subject: [splint-discuss] Re: Bogus warnings when assigning literals to uint8_t In-Reply-To: <200410271523.16649.terry-splint@tenberry.com> References: <20041027213048.GA27550@grante.dsl.visi.com> <200410271523.16649.terry-splint@tenberry.com> Message-ID: <20041027224037.GA27981@grante.dsl.visi.com> On Wed, Oct 27, 2004 at 03:23:16PM -0700, Terry Colligan wrote: > On Wednesday 27 October 2004 02:30 pm, Grant Edwards wrote: > I agree with Grant in every case here. Terry is obviously a scholar and a gentleman. ;) > In fact, we stopped using splint on our project exactly > because of this problem. I've been looking at the source code in hopes I could fix this issue, but it's not going to be easy. The actual value of the object on the right hand side doesn't seem to be available, so without some basic redesign there's no way to differentiate 5 from 5000. I can see two approaches to fix this: 1) Insted of passing around just an enumerated integer value that maps to a primitive C type, pass the value as well (when the value is known). 2) Define a new set of primitive C types for integral literal constants that reflect which types they will "fit" into. Option 1) appears to be pretty disruptive and would require re-writing a lot of stuff. I don't think option 2) would be as hard. That said, I don't really have time to work on either approach. I'm leaning towards agreeing with Terry on this problem being a show-stopper for splint. I've already spent a day and a half getting rid of pre-defined, hardwired macros that weren't right. It doesn't look like I can solve this problem in a reasonable amount of time. -- Grant Edwards grante@visi.com From Ralf.Wildenhues at gmx.de Thu Oct 28 02:35:13 2004 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:10:48 2006 Subject: [splint-discuss] Re: How to predefined a set of macros? In-Reply-To: <20041027212700.GA27405@grante.dsl.visi.com> References: <20041027161019.GA2355@grante.dsl.visi.com> <20041027200446.GA6356@uni-bonn.de> <20041027212700.GA27405@grante.dsl.visi.com> Message-ID: <20041028063513.GA31481@iam.uni-bonn.de> * Grant Edwards wrote on Wed, Oct 27, 2004 at 11:27:01PM CEST: > > > > What are you really trying to achieve? > > I want to check my code using the same set of headers that will > be used to compile it. Sometimes a good idea. Esp. with splint there are reasons against it sometimes, however. > > Your questions sound to me like you want to check system (or > > other installed) headers. > > Sure, why not? Errors in those headers will generate code > that's just as incorrect as errors in anything else. Besides, > it's compatibility of my code with those headers that actually > matters. Yes, sure. But that is best discovered by regular compilation against those headers. One reason against splint checking against them is that the installed headers are allowed to be (and generally are) unportable, can contain compiler- and/or system-specific extensions. Furthermore, they are usually not splint-annotated. The last item is not a show-stopper per se, but light annotation usually leads to much better checking results. A show-stopper is usually when you have to change a header in order for splint to be able to parse it (and you cannot change installed headers on that machine). > > Or need them to be able to check your code. > > Why isn't checking the same set of files you're handing to the > compiler a good idea? See above. > > I've found that the wrong way to use splint. Rather, let > > splint have a different set of headers > > Why would I want to write a second set of system headers when > I've already got a set? See above. Plus: to make really sure you only use publicized interfaces (compare e.g. +posixlib or +unixlib and the respective lib/ files in splint). > > and make them as clean as possible, add a few annotations > > where helpful. > > If you're going that direction, why not a completely different > set of C source files? ;) That's not necessary. And it's really not that much to do. For my purposes, I took existing header files for e.g. MPI and OpenMP and annotated them partly, one time started with pcre as well. I can make these available if anyone is interested. Regards, Ralf From grante at visi.com Thu Oct 28 09:48:20 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:48 2006 Subject: [splint-discuss] Re: How to predefined a set of macros? In-Reply-To: <20041028063513.GA31481@iam.uni-bonn.de> References: <20041027161019.GA2355@grante.dsl.visi.com> <20041027200446.GA6356@uni-bonn.de> <20041027212700.GA27405@grante.dsl.visi.com> <20041028063513.GA31481@iam.uni-bonn.de> Message-ID: <20041028134819.GA5514@grante.dsl.visi.com> On Thu, Oct 28, 2004 at 08:35:13AM +0200, Ralf Wildenhues wrote: >> I want to check my code using the same set of headers that >> will be used to compile it. > > Sometimes a good idea. Esp. with splint there are reasons > against it sometimes, however. Once I eliminated the incorrectly predefined macros, it worked fine. Splint had incorrectly defined __SIZE_TYPE__, __PTRDIFF_TYPE__, __WCHAR_TYPE__, the cpu type, and a couple others. Once that was fixed, there wasn't a single warning from system headers. >>> Your questions sound to me like you want to check system (or >>> other installed) headers. >> >> Sure, why not? Errors in those headers will generate code >> that's just as incorrect as errors in anything else. Besides, >> it's compatibility of my code with those headers that actually >> matters. > > Yes, sure. But that is best discovered by regular compilation > against those headers. One reason against splint checking against > them is that the installed headers are allowed to be (and generally > are) unportable, can contain compiler- and/or system-specific > extensions. So does my application code. :) > Furthermore, they are usually not splint-annotated. The last > item is not a show-stopper per se, but light annotation > usually leads to much better checking results. That makes sense, and it's definitley the best argument for writing your own set of header files, but I still don't have time to do so. > A show-stopper is usually when you have to change a header in > order for splint to be able to parse it (and you cannot change > installed headers on that machine). Mine all parsed just fine after I eliminated the pre-defined macros from splint and used the correct ones (the ones defined by the compiler). >> Why would I want to write a second set of system headers when >> I've already got a set? > > See above. Plus: to make really sure you only use publicized > interfaces (compare e.g. +posixlib or +unixlib and the > respective lib/ files in splint). I don't think I understand. The system's include files are the _definition_ of what's publicized by the system. -- Grant Edwards grante@visi.com From Ralf.Wildenhues at gmx.de Thu Oct 28 10:10:59 2004 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed Mar 22 17:10:48 2006 Subject: [splint-discuss] Re: How to predefined a set of macros? In-Reply-To: <20041028134819.GA5514@grante.dsl.visi.com> References: <20041027161019.GA2355@grante.dsl.visi.com> <20041027200446.GA6356@uni-bonn.de> <20041027212700.GA27405@grante.dsl.visi.com> <20041028063513.GA31481@iam.uni-bonn.de> <20041028134819.GA5514@grante.dsl.visi.com> Message-ID: <20041028141059.GA17122@iam.uni-bonn.de> * Grant Edwards wrote on Thu, Oct 28, 2004 at 03:48:20PM CEST: > On Thu, Oct 28, 2004 at 08:35:13AM +0200, Ralf Wildenhues wrote: > > >> I want to check my code using the same set of headers that > >> will be used to compile it. > > > > Sometimes a good idea. Esp. with splint there are reasons > > against it sometimes, however. > > Once I eliminated the incorrectly predefined macros, it worked > fine. Splint had incorrectly defined __SIZE_TYPE__, > __PTRDIFF_TYPE__, __WCHAR_TYPE__, the cpu type, and a > couple others. Once that was fixed, there wasn't a single > warning from system headers. Lucky you. Not all gcc extensions used in installed headers can/could be done away with preprocessor defines. > > One reason against splint checking against > > them is that the installed headers are allowed to be (and generally > > are) unportable, can contain compiler- and/or system-specific > > extensions. > > So does my application code. :) Well. One reason for using splint is to flag unportable stuff. > > Furthermore, they are usually not splint-annotated. The last > > item is not a show-stopper per se, but light annotation > > usually leads to much better checking results. > > That makes sense, and it's definitley the best argument for > writing your own set of header files, but I still don't have > time to do so. Easy. Just copy the ones you use to a separate splint-include dir. Almost no time. Annotate/throw out internals as time permits. > > A show-stopper is usually when you have to change a header in > > order for splint to be able to parse it (and you cannot change > > installed headers on that machine). > > Mine all parsed just fine after I eliminated the pre-defined > macros from splint and used the correct ones (the ones defined > by the compiler). Lucky you. > >> Why would I want to write a second set of system headers when > >> I've already got a set? > > > > See above. Plus: to make really sure you only use publicized > > interfaces (compare e.g. +posixlib or +unixlib and the > > respective lib/ files in splint). > > I don't think I understand. The system's include files are the > _definition_ of what's publicized by the system. Not always. Stupid example: within splint, FILE is an abstract type. Were you so unwise as to dereference a FILE * within your code, splint could tell you. Most likely, installed headers also reveal some of the internal details of that type, however. Carry the example over to other, more relevant examples (and don't tell me, nobody does things like that). Regards, Ralf From grante at visi.com Thu Oct 28 11:37:45 2004 From: grante at visi.com (Grant Edwards) Date: Wed Mar 22 17:10:48 2006 Subject: [splint-discuss] Re: How to predefined a set of macros? In-Reply-To: <20041028141059.GA17122@iam.uni-bonn.de> References: <20041027161019.GA2355@grante.dsl.visi.com> <20041027200446.GA6356@uni-bonn.de> <20041027212700.GA27405@grante.dsl.visi.com> <20041028063513.GA31481@iam.uni-bonn.de> <20041028134819.GA5514@grante.dsl.visi.com> <20041028141059.GA17122@iam.uni-bonn.de> Message-ID: <20041028153743.GA6652@grante.dsl.visi.com> On Thu, Oct 28, 2004 at 04:10:59PM +0200, Ralf Wildenhues wrote: >> Once I eliminated the incorrectly predefined macros, it worked >> fine. Splint had incorrectly defined __SIZE_TYPE__, >> __PTRDIFF_TYPE__, __WCHAR_TYPE__, the cpu type, and a >> couple others. Once that was fixed, there wasn't a single >> warning from system headers. > > Lucky you. Everybody gets lucky once in a while. :) > Not always. Stupid example: within splint, FILE is an > abstract type. Were you so unwise as to dereference a FILE * > within your code, splint could tell you. Most likely, > installed headers also reveal some of the internal details of > that type, however. Yes, I see your point. -- Grant Edwards grante@visi.com