From tydeman at tybor.com Tue Sep 1 16:56:04 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Tue, 01 Sep 2009 16:56:04 -0700 (PDT) Subject: [splint-discuss] Internal bug In-Reply-To: <200908311757.n7VHvel8013957@ares.cs.Virginia.EDU> Message-ID: <200909012356.n81NuBCL017771@ares.cs.Virginia.EDU> On Mon, 31 Aug 2009 10:57:31 -0700 (PDT), Fred J. Tydeman wrote: >Splint 3.1.2 --- 05 Sep 2008 >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 at splint.org *** > (attempting to continue, results may be incorrect) > >I assume some shell environment variable is causing this problem. >Any suggestions? Any idea which shell environment variables matter >to splint? splint help vars got me information about what splint was using from the shell environment. Using that as a hint, I experimented and found that export CPATH= was the statement causing the internal bug. I have removed that export from my setup and split works better. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From tydeman at tybor.com Tue Sep 1 17:04:03 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Tue, 01 Sep 2009 17:04:03 -0700 (PDT) Subject: [splint-discuss] Another Internal bug In-Reply-To: <200908311757.n7VHvel8013957@ares.cs.Virginia.EDU> Message-ID: <200909020004.n8204A8N018384@ares.cs.Virginia.EDU> With: splint test98.c 1>test98.lnt 2>test92.ln2 where test98.c is an empty file, .splintrc has: +show-scan +which-lib +sys-dirs /usr/lib/gcc/i386-redhat-linux/4.3.2/include:/usr/include # +ansi-lib # this or next +strict-lib +iso99-limits +D__CHAR_BIT__=8 +D__CHAR_BIT__ # +gnuextensions NOTE: that __CHAR_BIT__ is defined twice (I was experimenting). I also cannot find anything in the splint documentation on how to do those macro definitions. I gather the blanks are NOT liked. test98.lnt has: Command Line: Macro __CHAR_BIT__ already defined Command Line: Previous definition of __CHAR_BIT__ test98.ln2 has: Splint 3.1.2 --- 05 Sep 2008 Standard library: /usr/share/splint/lib/standardstrict.lcd < loading standard library /usr/share/splint/lib/standardstrict.lcd .... > context.c:196: at source point Command Line: *** Internal Bug at context.c:196: llassert failed: gc.preprocessing [errno: 2] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) < more preprocessing .llerror.c:128: at source point: protected fatal llassert failed: !s_needsPrepare --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From tydeman at tybor.com Tue Sep 1 23:09:56 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Tue, 01 Sep 2009 23:09:56 -0700 (PDT) Subject: [splint-discuss] How define multi-token symbol? Message-ID: <200909020610.n826A7kP015942@ares.cs.Virginia.EDU> How do I do the equivalent of #define sym long double in my .splintrc file? I have tried: +Dsym=long double but that gets an error on 'double' I have tried: +Dsym="long double" but is treated as a string. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From Wenzel at bbr-vt.de Tue Sep 1 23:59:55 2009 From: Wenzel at bbr-vt.de (Wenzel, Bodo) Date: Wed, 2 Sep 2009 08:59:55 +0200 Subject: [splint-discuss] How define multi-token symbol? In-Reply-To: <200909020610.n826A7kP015942@ares.cs.Virginia.EDU> References: <200909020610.n826A7kP015942@ares.cs.Virginia.EDU> Message-ID: <46B6459B655D7342AB97371E8B7CD8B8810AF9@sv-exch.BBR.local> Try +D"sym=long double" Though I had no success as "sym" is _not_ replaced. However, I'm running Splint 3.1.1 on Win2K here, so your mileage might vary. To get around include file problems the option "-preproc" was added, too. HTH, Bodo From rbonacina at robur.it Wed Sep 2 00:23:13 2009 From: rbonacina at robur.it (Roberto Bonacina) Date: Wed, 02 Sep 2009 09:23:13 +0200 Subject: [splint-discuss] R: How define multi-token symbol? In-Reply-To: <200909020610.n826A7kP015942@ares.cs.Virginia.EDU> Message-ID: <000001ca2b9e$3b230b60$e601a8c0@ARSENICO> I think you should use -Dsym=long double and not +Dsym=long double but I don't know if this could solve your problem. Regards, Roberto > -----Messaggio originale----- > Da: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] Per conto di > Fred J. Tydeman > Inviato: mercoled? 2 settembre 2009 8.10 > A: splint-discuss at mail.cs.virginia.edu > Oggetto: [splint-discuss] How define multi-token symbol? > > > How do I do the equivalent of > #define sym long double > in my .splintrc file? > > I have tried: > +Dsym=long double > but that gets an error on 'double' > > I have tried: > +Dsym="long double" > but is treated as a string. > > --- > Fred J. Tydeman Tydeman Consulting > tydeman at tybor.com Testing, numerics, programming > +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") > Sample C99+FPCE tests: http://www.tybor.com > Savers sleep well, investors eat well, spenders work forever. > > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss > From tydeman at tybor.com Wed Sep 2 12:33:03 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Wed, 02 Sep 2009 12:33:03 -0700 (PDT) Subject: [splint-discuss] R: How define multi-token symbol? In-Reply-To: <000001ca2b9e$3b230b60$e601a8c0@ARSENICO> Message-ID: <200909021933.n82JXEHN021944@ares.cs.Virginia.EDU> On Wed, 02 Sep 2009 09:23:13 +0200, Roberto Bonacina wrote: >I think you should use >-Dsym=long double Same problem. The documentation says that +D and -D are the same. I also tried: +D"sym=long double" "+Dsym=long double" +Dsym='long double' +Dsym=\long double\ None of them worked. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From tydeman at tybor.com Wed Sep 2 12:35:42 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Wed, 02 Sep 2009 12:35:42 -0700 (PDT) Subject: [splint-discuss] limits.lcl In-Reply-To: <200908311757.n7VHvel8013957@ares.cs.Virginia.EDU> Message-ID: <200909021935.n82JZrT9022285@ares.cs.Virginia.EDU> In looking at the file limits.lcl in the splint directory tree, I notice that LDBL_MAX is 'double', instead of the expected 'long double'. That seems weird to me. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From tydeman at tybor.com Wed Sep 2 12:37:41 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Wed, 02 Sep 2009 12:37:41 -0700 (PDT) Subject: [splint-discuss] More Internal bugs In-Reply-To: <200908311757.n7VHvel8013957@ares.cs.Virginia.EDU> Message-ID: <200909021937.n82JbnN8022557@ares.cs.Virginia.EDU> Splint 3.1.2 --- 05 Sep 2008 Standard library: /usr/share/splint/lib/standardstrict.lcd < loading standard library /usr/share/splint/lib/standardstrict.lcd .... > < preprocessing > < checking s0000000.c > s0000000.c:672:2: *** Internal Bug at constraintGeneration.c:1441: Unsupported preop in +9.9e99999L [errno: 34] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) s0000000.c:672:2: *** Internal Bug at constraintGeneration.c:1442: constraintGeneration.c:1442: llassert failed: FALSE: Reached dead code! [errno: 34] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) The line mentioned in the error message is the '}' that ends a function. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From Michael.Wojcik at MicroFocus.com Wed Sep 2 13:44:37 2009 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed, 2 Sep 2009 13:44:37 -0700 Subject: [splint-discuss] R: How define multi-token symbol? In-Reply-To: <200909021933.n82JXEHN021944@ares.cs.Virginia.EDU> References: <000001ca2b9e$3b230b60$e601a8c0@ARSENICO> <200909021933.n82JXEHN021944@ares.cs.Virginia.EDU> Message-ID: <81F42F63D5BB344ABF294F8E80990C79084F1F@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu [mailto:splint-discuss- > bounces at cs.virginia.edu] On Behalf Of Fred J. Tydeman > Sent: Wednesday, 02 September, 2009 15:33 > > On Wed, 02 Sep 2009 09:23:13 +0200, Roberto Bonacina wrote: > > >I think you should use > >-Dsym=long double > > Same problem. The documentation says that +D and -D are the same. > > I also tried: > +D"sym=long double" > "+Dsym=long double" > +Dsym='long double' > +Dsym=\long double\ > > None of them worked. Nor does: -Dsym=long\ double which seemed like it'd be worth a try. I suspect this simply isn't supported; probably no one's needed it before, or when they discovered it didn't work, they couldn't be bothered to fix it. I don't know that there's a lot of maintenance being done on Splint. Bugs generally seem to be fixed by the people who find them. Since it's open source, I might take a look at some of these issues if I get some free time - but that's a big if, to be honest. That said, it's good that you're posting these issues to the list, so that they're at least documented. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From splint at sympatico.ca Wed Sep 2 20:44:14 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 02 Sep 2009 22:44:14 -0500 Subject: [splint-discuss] More Internal bugs In-Reply-To: <200909021937.n82JbnN8022557@ares.cs.Virginia.EDU> (Fred J. Tydeman's message of "Wed, 02 Sep 2009 12:37:41 -0700 (PDT)") References: <200909021937.n82JbnN8022557@ares.cs.Virginia.EDU> Message-ID: <87eiqor8tt.fsf@sympatico.ca> On 2 Sep 2009, tydeman at tybor.com wrote: > Splint 3.1.2 --- 05 Sep 2008 > > Standard library: /usr/share/splint/lib/standardstrict.lcd > < loading standard library /usr/share/splint/lib/standardstrict.lcd .... > > < preprocessing > > < checking s0000000.c > > s0000000.c:672:2: *** Internal Bug at constraintGeneration.c:1441: > Unsupported preop in +9.9e99999L [errno: 34] > *** Please report bug to splint-bug at splint.org *** > (attempting to continue, results may be incorrect) > s0000000.c:672:2: *** Internal Bug at constraintGeneration.c:1442: > constraintGeneration.c:1442: llassert failed: FALSE: > Reached dead code! [errno: 34] > *** Please report bug to splint-bug at splint.org *** > (attempting to continue, results may be incorrect) > The line mentioned in the error message is the '}' that > ends a function. Does the file have a missing brace? Your description is not enough to solve the problem. It is trying to parse an expression like "++i" or "i++". There is something wrong with your input (and/or pre-processing). I am not quite sure why the parser wouldn't have aborted in this case. It would be much easier to diagnose with a reduce input file and the full command line. Thanks, -- My kid had sex with your honor student. - Bumper Sticker From splint at sympatico.ca Wed Sep 2 20:44:14 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 02 Sep 2009 22:44:14 -0500 Subject: [splint-discuss] More Internal bugs In-Reply-To: <200909021937.n82JbnN8022557@ares.cs.Virginia.EDU> (Fred J. Tydeman's message of "Wed, 02 Sep 2009 12:37:41 -0700 (PDT)") References: <200909021937.n82JbnN8022557@ares.cs.Virginia.EDU> Message-ID: <87eiqor8tt.fsf@sympatico.ca> On 2 Sep 2009, tydeman at tybor.com wrote: > Splint 3.1.2 --- 05 Sep 2008 > > Standard library: /usr/share/splint/lib/standardstrict.lcd > < loading standard library /usr/share/splint/lib/standardstrict.lcd .... > > < preprocessing > > < checking s0000000.c > > s0000000.c:672:2: *** Internal Bug at constraintGeneration.c:1441: > Unsupported preop in +9.9e99999L [errno: 34] > *** Please report bug to splint-bug at splint.org *** > (attempting to continue, results may be incorrect) > s0000000.c:672:2: *** Internal Bug at constraintGeneration.c:1442: > constraintGeneration.c:1442: llassert failed: FALSE: > Reached dead code! [errno: 34] > *** Please report bug to splint-bug at splint.org *** > (attempting to continue, results may be incorrect) > The line mentioned in the error message is the '}' that > ends a function. Does the file have a missing brace? Your description is not enough to solve the problem. It is trying to parse an expression like "++i" or "i++". There is something wrong with your input (and/or pre-processing). I am not quite sure why the parser wouldn't have aborted in this case. It would be much easier to diagnose with a reduce input file and the full command line. Thanks, -- My kid had sex with your honor student. - Bumper Sticker From splint at sympatico.ca Wed Sep 2 20:33:47 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 02 Sep 2009 22:33:47 -0500 Subject: [splint-discuss] R: How define multi-token symbol? In-Reply-To: <200909021933.n82JXEHN021944@ares.cs.Virginia.EDU> (Fred J. Tydeman's message of "Wed, 02 Sep 2009 12:33:03 -0700 (PDT)") References: <200909021933.n82JXEHN021944@ares.cs.Virginia.EDU> Message-ID: <87iqg0r9b8.fsf@sympatico.ca> On 2 Sep 2009, tydeman at tybor.com wrote: > Same problem. The documentation says that +D and -D are the same. > > I also tried: > +D"sym=long double" > "+Dsym=long double" > +Dsym='long double' > +Dsym=\long double\ > > None of them worked. The option -Dsym="long double" seems to work from the command line. As should -Dsym=long\ double. These do not work when read from a file and there may be a .splintrc file that is being read. Also, it seem that the command line parsing relies on the argv globbing from the OS. Depending on what platform you are running ymmv. bpringle at pvr:/home/src/splint/src$ cat foo.c #ifdef sym static sym junk = 1.0; static long double test = 2.0; /*@unused@*/ void tester(void) { test = junk; } #endif bpringle at pvr:/home/src/splint/src$ ./splint -exportheader -Dsym="long double" foo.c Splint 3.1.2 --- 02 Sep 2009 < loading standard library /home/src/splint/lib/posix.lcd .... > < preprocessing > < checking foo.c > < global checks > Finished checking --- no warnings 8 source lines in 0.01 s. Time distribution (percent): initialize 100.00 / pre-process 0.00 / c check 0.00 / finalize 0.00 bpringle at pvr:/home/src/splint/src$ ./splint -exportheader -Dsym="long" foo.c Splint 3.1.2 --- 02 Sep 2009 < loading standard library /home/src/splint/lib/posix.lcd .... > < preprocessing > < checking foo.c > foo.c:2:20: Variable junk initialized to type double, expects long int: 1.0 To allow all numeric types to match, use +relaxtypes. foo.c: (in function tester) foo.c:6:5: Assignment of long int to long double: test = junk < global checks > Error Type Reported Suppressed =================== ======== ========= relaxtypes 2 0 ======== ========= Total 2 0 Finished checking --- 2 code warnings 8 source lines Fwiw, -- All my best thoughts were stolen by the ancients. - Ralph Waldo Emerson From aeh at db.org Fri Sep 4 00:46:40 2009 From: aeh at db.org (Alfred E. Heggestad) Date: Fri, 04 Sep 2009 09:46:40 +0200 Subject: [splint-discuss] splint 3.1.2 Internal Bug at constraintGeneration.c:313 Message-ID: <4AA0C5E0.9020304@db.org> Hi I am using Splint v3.1.2 and some of my source code makes it crash. Using splint v3.1.1 works fine. Here is the crash: Splint 3.1.2 --- 04 Sep 2009 constraintGeneration.c:313: at source point test.c:14:2: *** Internal Bug at constraintGeneration.c:313: llassert failed: exprNode_isDefined(test) [errno: 25] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) *** Segmentation Violation *** Location (not trusted): test.c:14:2 *** Last code point: transferChecks.c:4415 *** Previous code point: transferChecks.c:4002 *** Please report bug to splint-bug at splint.org *** A useful bug report should include everything we need to reproduce the bug. Here is a code snippet to reproduce: ---------------------------------------------------- #include #include typedef int (handler_h)(int c); static int test(handler_h *h, char c) { if (h(c)) return 1; return 0; } int main(void) { printf("%d\n", test(isdigit, '1')); printf("%d\n", test(isalpha, 'a')); return 0; } ---------------------------------------------------- the issue is the checking of the return code from the 'h' function handler. if the code is split up to first assign the return code to a variable, and then check the variable, there is no crash. /alfred From splint at sympatico.ca Tue Sep 8 19:57:33 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Tue, 08 Sep 2009 21:57:33 -0500 Subject: [splint-discuss] splint 3.1.2 Internal Bug at constraintGeneration.c:313 In-Reply-To: <4AA0C5E0.9020304@db.org> (Alfred E. Heggestad's message of "Fri, 04 Sep 2009 09:46:40 +0200") References: <4AA0C5E0.9020304@db.org> Message-ID: <87k508esf6.fsf@sympatico.ca> On 4 Sep 2009, aeh at db.org wrote: > Here is the crash: > Splint 3.1.2 --- 04 Sep 2009 > constraintGeneration.c:313: at source point > test.c:14:2: *** Internal Bug at constraintGeneration.c:313: llassert failed: > Here is a code snippet to reproduce: > typedef int (handler_h)(int c); > static int test(handler_h *h, char c) > { > if (h(c)) > return 1; > > return 0; > } The proper way to define a function pointer is like this, typedef int (*handler_h)(int c); I am not really sure that the code you have is correct. Some compilers may except it. It would be appropriate for splint to tell you that it had a parse error in this case. If you don't think this is that case (point me to some standard) and have better behavior please tell me. Thanks, Bill Pringlemeir. -- Little girls, like butterflies need no excuses. - Robert Heinlein From splint at sympatico.ca Tue Sep 8 19:57:33 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Tue, 08 Sep 2009 21:57:33 -0500 Subject: [splint-discuss] splint 3.1.2 Internal Bug at constraintGeneration.c:313 In-Reply-To: <4AA0C5E0.9020304@db.org> (Alfred E. Heggestad's message of "Fri, 04 Sep 2009 09:46:40 +0200") References: <4AA0C5E0.9020304@db.org> Message-ID: <87k508esf6.fsf@sympatico.ca> On 4 Sep 2009, aeh at db.org wrote: > Here is the crash: > Splint 3.1.2 --- 04 Sep 2009 > constraintGeneration.c:313: at source point > test.c:14:2: *** Internal Bug at constraintGeneration.c:313: llassert failed: > Here is a code snippet to reproduce: > typedef int (handler_h)(int c); > static int test(handler_h *h, char c) > { > if (h(c)) > return 1; > > return 0; > } The proper way to define a function pointer is like this, typedef int (*handler_h)(int c); I am not really sure that the code you have is correct. Some compilers may except it. It would be appropriate for splint to tell you that it had a parse error in this case. If you don't think this is that case (point me to some standard) and have better behavior please tell me. Thanks, Bill Pringlemeir. -- Little girls, like butterflies need no excuses. - Robert Heinlein From splint at sympatico.ca Tue Sep 8 20:19:15 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Tue, 08 Sep 2009 22:19:15 -0500 Subject: [splint-discuss] More Internal bugs In-Reply-To: <20090903055822.FUHI1582.tomts17-srv.bellnexxia.net@toip26.srvr.bell.ca> (Fred J. Tydeman's message of "Wed, 02 Sep 2009 22:58:10 -0700 (PDT)") References: <20090903055822.FUHI1582.tomts17-srv.bellnexxia.net@toip26.srvr.bell.ca> Message-ID: <874orcerf0.fsf@sympatico.ca> On Wed, 02 Sep 2009 22:44:14 -0500, Bill Pringlemeir wrote: >> Does the file have a missing brace? Your description is not enough to >> solve the problem. It is trying to parse an expression like "++i" or >> "i++". There is something wrong with your input (and/or >> pre-processing). I am not quite sure why the parser wouldn't have >> aborted in this case. It would be much easier to diagnose with a >> reduce input file and the full command line. On 3 Sep 2009, tydeman at tybor.com wrote: > Attached is the source file. The value 9.9e9999L comes from INF_LDBL. > I will be gone for the next 3 to 5 days without email access. > This code has been processed by at least 10 C compilers without > problems (I test compilers for a living). Thanks. It is not really a reduced code set. You have a snippet like '+INF_LDBL' in this area of code. When I attempt to process the file I have, bpringle at pvr:/home/src/splint/src$ ./splint S0000000.c Splint 3.1.2 --- 08 Sep 2009 < loading standard library /home/src/splint/lib/posix.lcd .... > < preprocessing > S0000000.c:115:21: Cannot find include file mydefs.h on search path: /home/src/splint/src;Headers;/usr/include;/usr/local/include Preprocessing error. (Use -preproc to inhibit warning) < more preprocessing . > S0000000.c:144:16: Preprocessor command #include expects "FILENAME" or < more preprocessing . > S0000000.c:154:21: Preprocessor command #include expects "FILENAME" or < more preprocessing . > S0000000.c:159:56: Cannot find include file myfloat.h on search path: /home/src/splint/src;Headers;/usr/include;/usr/local/include < more preprocessing . > S0000000.c:160:62: Cannot find include file myfuncs.h on search path: /home/src/splint/src;Headers;/usr/include;/usr/local/include < more preprocessing . > S0000000.c:204:72: #error CHAR_BIT not 8. Internal to hex translation code needs work. < more preprocessing . > S0000000.c:212:54: #error Need to know a 32-bit type; contact Tydeman < more preprocessing . > S0000000.c:890:59: Invalid character in #if: \ < more preprocessing . > Preprocessing error for file: /home/src/splint/src/S0000000.c *** Cannot continue. Splint seem to have trouble with the multi-line '#if'. Do you have the same problem with the conditions defined? The last error is not too helpful. Fixing that I get, bpringle at pvr:/home/src/splint/src$ ./splint S0000000.c Splint 3.1.2 --- 08 Sep 2009 < loading standard library /home/src/splint/lib/posix.lcd .... > < preprocessing > S0000000.c:115:21: Cannot find include file mydefs.h on search path: /home/src/splint/src;Headers;/usr/include;/usr/local/include Preprocessing error. (Use -preproc to inhibit warning) < more preprocessing . > S0000000.c:144:16: Preprocessor command #include expects "FILENAME" or < more preprocessing . > S0000000.c:154:21: Preprocessor command #include expects "FILENAME" or < more preprocessing . > S0000000.c:159:56: Cannot find include file myfloat.h on search path: /home/src/splint/src;Headers;/usr/include;/usr/local/include < more preprocessing . > S0000000.c:160:62: Cannot find include file myfuncs.h on search path: /home/src/splint/src;Headers;/usr/include;/usr/local/include < more preprocessing . > S0000000.c:204:72: #error CHAR_BIT not 8. Internal to hex translation code needs work. < more preprocessing . > S0000000.c:212:54: #error Need to know a 32-bit type; contact Tydeman < more preprocessing . > Preprocessing error for file: /home/src/splint/src/S0000000.c *** Cannot continue. I think that the issue was reported here, https://sourceforge.net/tracker/?func=detail&aid=1837229&group_id=34302&atid=459911 You would need to get the current CVS head to test this. Thanks, Bill Pringlemeir. -- Feynman on QED: I don't understand it. Nobody does. From Wenzel at bbr-vt.de Tue Sep 8 22:59:39 2009 From: Wenzel at bbr-vt.de (Wenzel, Bodo) Date: Wed, 9 Sep 2009 07:59:39 +0200 Subject: [splint-discuss] splint 3.1.2 Internal Bug atconstraintGeneration.c:313 In-Reply-To: <87k508esf6.fsf@sympatico.ca> References: <4AA0C5E0.9020304@db.org> <87k508esf6.fsf@sympatico.ca> Message-ID: <46B6459B655D7342AB97371E8B7CD8B8855D62@sv-exch.BBR.local> >> typedef int (handler_h)(int c); >> >> static int test(handler_h *h, char c) > [...] > The proper way to define a function pointer is like this, > > typedef int (*handler_h)(int c); > > I am not really sure that the code you have is correct. Well, I think the source is correct. As I found in the standard, 'handler_h' is a defined type of a function receiving an int and returning an int, not a pointer to such. And 'test()' is defined with the first argument being a pointer to 'handler_h'. If the second typedef is used, 'test()' should be defined as static int test(handler_h h, char c) However, I think in either case the call of the given function should be if ((*h)()) Bodo From Michael.Wojcik at MicroFocus.com Wed Sep 9 05:41:42 2009 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Wed, 9 Sep 2009 05:41:42 -0700 Subject: [splint-discuss] splint 3.1.2 Internal BugatconstraintGeneration.c:313 In-Reply-To: <46B6459B655D7342AB97371E8B7CD8B8855D62@sv-exch.BBR.local> References: <4AA0C5E0.9020304@db.org> <87k508esf6.fsf@sympatico.ca> <46B6459B655D7342AB97371E8B7CD8B8855D62@sv-exch.BBR.local> Message-ID: <81F42F63D5BB344ABF294F8E80990C79084F4D@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu [mailto:splint-discuss- > bounces at cs.virginia.edu] On Behalf Of Wenzel, Bodo > Sent: Wednesday, 09 September, 2009 02:00 > To: Discussions about the Splint annotation-assisted static > analysisproject > > [unattributed] > > The proper way to define a function pointer is like this, > > > > typedef int (*handler_h)(int c); That's a conventional idiom for defining a function pointer, but nothing makes it "the proper way". > >> typedef int (handler_h)(int c); > >> > >> static int test(handler_h *h, char c) > > As I found in the standard, 'handler_h' is a defined type of a function > receiving an int and returning an int, not a pointer to such. And > 'test()' is defined with the first argument being a pointer to > 'handler_h'. Correct, though remember that typedef does not actually define a type, but a type alias (its name and the language in the standard notwithstanding). Note the standard has an example of precisely this sort of typedef: EXAMPLE 1 After typedef int MILES, KLICKSP(); typedef struct { double hi, lo; } range; the constructions MILES distance; extern KLICKSP *metricp; range x; range z, *zp; are all valid declarations. The type of distance is int, that of metricp is "pointer to function with no parameter specification returning int", ... (6.7.7 #4) Also note the parentheses around the identifier "handler_h" in the typedef definition are unnecessary. > However, I think in either case the call of the given function should > be > > if ((*h)()) The indirection operator and parentheses around "*h" are redundant. The function-call operator takes an operand of type "pointer to function". Most often this is a function identifier that decays to type pointer-to-function, but if the identifier happens to be of type pointer-to-function already, it's used as-is. Thus: int (*h)(void); ... if (h()) is perfectly correct. Some people like to use (*h) to indicate at the point of use that h is a function pointer, but I don't see that as a particularly useful piece of information - if it's potentially unclear to maintainers, add a comment. The extra asterisk and parentheses are just visual clutter. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From tydeman at tybor.com Wed Sep 9 11:31:36 2009 From: tydeman at tybor.com (Fred J. Tydeman) Date: Wed, 09 Sep 2009 11:31:36 -0700 (PDT) Subject: [splint-discuss] More Internal bugs In-Reply-To: <874orcerf0.fsf@sympatico.ca> Message-ID: <200909091832.n89IW0Th014047@ares.cs.Virginia.EDU> On Tue, 08 Sep 2009 22:19:15 -0500, Bill Pringlemeir wrote: >On Wed, 02 Sep 2009 22:44:14 -0500, Bill Pringlemeir wrote: > >>> Does the file have a missing brace? Your description is not enough to >>> solve the problem. It is trying to parse an expression like "++i" or >>> "i++". There is something wrong with your input (and/or >>> pre-processing). I am not quite sure why the parser wouldn't have >>> aborted in this case. It would be much easier to diagnose with a >>> reduce input file and the full command line. > >On 3 Sep 2009, tydeman at tybor.com wrote: > >> Attached is the source file. The value 9.9e9999L comes from INF_LDBL. >> I will be gone for the next 3 to 5 days without email access. >> This code has been processed by at least 10 C compilers without >> problems (I test compilers for a living). > >Thanks. It is not really a reduced code set. You have a snippet like >'+INF_LDBL' in this area of code. I have created a reduced code set to show the problem. Attached are two files: splint.rc == .splintrc test97.c and the result file: test97.ln2 --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 6088 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090909/8564be00/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 3237 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090909/8564be00/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 714 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090909/8564be00/attachment-0005.obj From splint at sympatico.ca Wed Sep 9 16:31:34 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 09 Sep 2009 18:31:34 -0500 Subject: [splint-discuss] More Internal bugs In-Reply-To: <200909091832.n89IW0Th014047@ares.cs.Virginia.EDU> (Fred J. Tydeman's message of "Wed, 09 Sep 2009 11:31:36 -0700 (PDT)") References: <200909091832.n89IW0Th014047@ares.cs.Virginia.EDU> Message-ID: <87ljkny9t5.fsf@sympatico.ca> On Tue, 08 Sep 2009 22:19:15 -0500, Bill Pringlemeir wrote: >> Thanks. It is not really a reduced code set. You have a snippet like >> '+INF_LDBL' in this area of code. On 9 Sep 2009, tydeman at tybor.com wrote: > I have created a reduced code set to show the problem. > Attached are two files: > splint.rc == .splintrc > test97.c This is with the change to constraintGeneration.c commented, $ ../splint -f SPLINT.RC TEST97.C Splint 3.1.2 --- 08 Sep 2009 Standard library: /home/src/splint/lib/standardstrict.lcd < loading standard library /home/src/splint/lib/standardstrict.lcd .... > < preprocessing > < checking TEST97.C > TEST97.C:122:2: *** Internal Bug at constraintGeneration.c:1445: Unsupported preop in +9.9e99999L [errno: 34] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) TEST97.C:122:2: *** Internal Bug at constraintGeneration.c:1446: constraintGeneration.c:1446: llassert failed: FALSE: Reached dead code! [errno: 34] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) This is with the latest contraintGeneration.c from CVS, $ ../splint -f SPLINT.RC TEST97.C Splint 3.1.2 --- 08 Sep 2009 Standard library: /home/src/splint/lib/standardstrict.lcd < loading standard library /home/src/splint/lib/standardstrict.lcd .... > < preprocessing > < checking TEST97.C > < global checks > TEST97.C:65: Function exported but not used outside TEST97: isnan A declaration is exported, but not used outside this module. Declaration can use static qualifier. (Use -exportlocal to inhibit warning) Finished checking --- 1 code warning The problem is hinted at in the output, Unsupported preop in +9.9e99999L [errno: 34] Prior versions of splint did not like a '+' leading a condition. The '+' token has a dual meaning, but the splint lexer/grammar seem to keep the same value/token for both. The minus is similar and was being handled differently for the if 'preop-eration' check. I have made them the same. Thanks, Bill Pringlemeir. -- Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. - Freire From splint at sympatico.ca Wed Sep 9 16:31:34 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 09 Sep 2009 18:31:34 -0500 Subject: [splint-discuss] More Internal bugs In-Reply-To: <200909091832.n89IW0Th014047@ares.cs.Virginia.EDU> (Fred J. Tydeman's message of "Wed, 09 Sep 2009 11:31:36 -0700 (PDT)") References: <200909091832.n89IW0Th014047@ares.cs.Virginia.EDU> Message-ID: <87ljkny9t5.fsf@sympatico.ca> On Tue, 08 Sep 2009 22:19:15 -0500, Bill Pringlemeir wrote: >> Thanks. It is not really a reduced code set. You have a snippet like >> '+INF_LDBL' in this area of code. On 9 Sep 2009, tydeman at tybor.com wrote: > I have created a reduced code set to show the problem. > Attached are two files: > splint.rc == .splintrc > test97.c This is with the change to constraintGeneration.c commented, $ ../splint -f SPLINT.RC TEST97.C Splint 3.1.2 --- 08 Sep 2009 Standard library: /home/src/splint/lib/standardstrict.lcd < loading standard library /home/src/splint/lib/standardstrict.lcd .... > < preprocessing > < checking TEST97.C > TEST97.C:122:2: *** Internal Bug at constraintGeneration.c:1445: Unsupported preop in +9.9e99999L [errno: 34] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) TEST97.C:122:2: *** Internal Bug at constraintGeneration.c:1446: constraintGeneration.c:1446: llassert failed: FALSE: Reached dead code! [errno: 34] *** Please report bug to splint-bug at splint.org *** (attempting to continue, results may be incorrect) This is with the latest contraintGeneration.c from CVS, $ ../splint -f SPLINT.RC TEST97.C Splint 3.1.2 --- 08 Sep 2009 Standard library: /home/src/splint/lib/standardstrict.lcd < loading standard library /home/src/splint/lib/standardstrict.lcd .... > < preprocessing > < checking TEST97.C > < global checks > TEST97.C:65: Function exported but not used outside TEST97: isnan A declaration is exported, but not used outside this module. Declaration can use static qualifier. (Use -exportlocal to inhibit warning) Finished checking --- 1 code warning The problem is hinted at in the output, Unsupported preop in +9.9e99999L [errno: 34] Prior versions of splint did not like a '+' leading a condition. The '+' token has a dual meaning, but the splint lexer/grammar seem to keep the same value/token for both. The minus is similar and was being handled differently for the if 'preop-eration' check. I have made them the same. Thanks, Bill Pringlemeir. -- Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. - Freire From aeh at db.org Thu Sep 10 11:28:00 2009 From: aeh at db.org (Alfred E. Heggestad) Date: Thu, 10 Sep 2009 20:28:00 +0200 Subject: [splint-discuss] splint 3.1.2 Internal Bug at constraintGeneration.c:313 In-Reply-To: <87k508esf6.fsf@sympatico.ca> References: <4AA0C5E0.9020304@db.org> <87k508esf6.fsf@sympatico.ca> Message-ID: <4AA94530.6040808@db.org> Bill Pringlemeir wrote: > On 4 Sep 2009, aeh at db.org wrote: > >> Here is the crash: > >> Splint 3.1.2 --- 04 Sep 2009 > >> constraintGeneration.c:313: at source point >> test.c:14:2: *** Internal Bug at constraintGeneration.c:313: llassert failed: > >> Here is a code snippet to reproduce: > >> typedef int (handler_h)(int c); > >> static int test(handler_h *h, char c) >> { >> if (h(c)) >> return 1; >> >> return 0; >> } > > > The proper way to define a function pointer is like this, > > typedef int (*handler_h)(int c); > Hi, the same code can also be written as: typedef int (*handler_h)(int c); static int test(handler_h h, char c) { if (h(c)) return 1; return 0; } ... that just "moves" the pointer from the parameter to the typedef. the execution of h(c) should be exactly the same. > I am not really sure that the code you have is correct. Some > compilers may except it. It would be appropriate for splint to tell > you that it had a parse error in this case. > I think the code is correct, I have used the same construct in many projects, compiled successfully with gcc and other compilers.. /alfred > If you don't think this is that case (point me to some standard) and > have better behavior please tell me. > > Thanks, > Bill Pringlemeir. > From aeh at db.org Thu Sep 10 11:28:00 2009 From: aeh at db.org (Alfred E. Heggestad) Date: Thu, 10 Sep 2009 20:28:00 +0200 Subject: [splint-discuss] splint 3.1.2 Internal Bug at constraintGeneration.c:313 In-Reply-To: <87k508esf6.fsf@sympatico.ca> References: <4AA0C5E0.9020304@db.org> <87k508esf6.fsf@sympatico.ca> Message-ID: <4AA94530.6040808@db.org> Bill Pringlemeir wrote: > On 4 Sep 2009, aeh at db.org wrote: > >> Here is the crash: > >> Splint 3.1.2 --- 04 Sep 2009 > >> constraintGeneration.c:313: at source point >> test.c:14:2: *** Internal Bug at constraintGeneration.c:313: llassert failed: > >> Here is a code snippet to reproduce: > >> typedef int (handler_h)(int c); > >> static int test(handler_h *h, char c) >> { >> if (h(c)) >> return 1; >> >> return 0; >> } > > > The proper way to define a function pointer is like this, > > typedef int (*handler_h)(int c); > Hi, the same code can also be written as: typedef int (*handler_h)(int c); static int test(handler_h h, char c) { if (h(c)) return 1; return 0; } ... that just "moves" the pointer from the parameter to the typedef. the execution of h(c) should be exactly the same. > I am not really sure that the code you have is correct. Some > compilers may except it. It would be appropriate for splint to tell > you that it had a parse error in this case. > I think the code is correct, I have used the same construct in many projects, compiled successfully with gcc and other compilers.. /alfred > If you don't think this is that case (point me to some standard) and > have better behavior please tell me. > > Thanks, > Bill Pringlemeir. > From Michael.Wojcik at microfocus.com Thu Sep 10 18:28:37 2009 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 10 Sep 2009 18:28:37 -0700 Subject: [splint-discuss] splint 3.1.2 Internal Bugat constraintGeneration.c:313 In-Reply-To: <4AA94530.6040808@db.org> References: <4AA0C5E0.9020304@db.org> <87k508esf6.fsf@sympatico.ca> <4AA94530.6040808@db.org> Message-ID: <81F42F63D5BB344ABF294F8E80990C79084F5E@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu [mailto:splint-discuss- > bounces at cs.virginia.edu] On Behalf Of Alfred E. Heggestad > Sent: Thursday, 10 September, 2009 14:28 > > Bill Pringlemeir wrote: > > > I am not really sure that the code you have is correct. Some > > compilers may except it. It would be appropriate for splint to tell > > you that it had a parse error in this case. > > I think the code is correct, I have used the same construct in many > projects, compiled successfully with gcc and other compilers.. An implementation can accept anything it likes. That says nothing about whether the construct complies with the standard. In this case, it does, and Splint is wrong; but in general, the fact that a construct works with several compilers is not a useful piece of evidence. The standard is very nearly available free. People in the US can get it from ANSI for $18; anyone can download various drafts that are suitable for nearly all purposes. There's really no reason to debate whether something as clear-cut as this is allowed by the standard. As I pointed out in my previous note, precisely the construct discussed in this thread appears as an example. > > If you don't think this is that case (point me to some standard) and > > have better behavior please tell me. The standard in question is ISO 9899-1999. Refer to 6.7.7 #4. If you don't have a copy, you can download the final draft (n869) as PDF, PS, or plain text, from [1], or the draft of 9899-1999 plus TC1 and TC2 (n1124) as PDF from [2]. [1] http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/ [2] http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf -- Michael Wojcik Principal Software Systems Developer, Micro Focus From splint at sympatico.ca Tue Sep 15 08:42:15 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Tue, 15 Sep 2009 10:42:15 -0500 Subject: [splint-discuss] splint 3.1.2 Internal Bug at constraintGeneration.c:313 In-Reply-To: <81F42F63D5BB344ABF294F8E80990C79084F5E@MTV-EXCHANGE.microfocus.com> (Michael Wojcik's message of "Thu, 10 Sep 2009 18:28:37 -0700") References: <4AA0C5E0.9020304@db.org> <87k508esf6.fsf@sympatico.ca> <4AA94530.6040808@db.org> <81F42F63D5BB344ABF294F8E80990C79084F5E@MTV-EXCHANGE.microfocus.com> Message-ID: <877hw0rz8o.fsf_-_@sympatico.ca> On 10 Sep 2009, Michael.Wojcik at microfocus.com wrote: >> Bill Pringlemeir wrote: >>> I am not really sure that the code you have is correct. Some >>> compilers may except it. It would be appropriate for splint to tell >>> you that it had a parse error in this case. >> I think the code is correct, I have used the same construct in many >> projects, compiled successfully with gcc and other compilers.. > An implementation can accept anything it likes. That says nothing about > whether the construct complies with the standard. > In this case, it does, and Splint is wrong; but in general, the fact > that a construct works with several compilers is not a useful piece of > evidence. > The standard is very nearly available free. Yes. Sorry, I posted the comment late at night. I have seen many spurious warnings. For instance, if (h(c) != 0) return 1; will produce [wrong] warnings about pointer comparisons. This has to do with the way splint is handling the semantics of calls through a function pointer. It is not a 'bug' as it is an un-implemented feature. Ie, there is not something wrong in the code... there is no code to handle this. http://www.splint.org/bugs.html, entry function pointers and memory management. I was wondering how, handler_h (*chained_function_pointer)(char c); should be handled, but I guess the parameters (even an empty brackets) give the parser context on which case to handle. Fortunately, we didn't get to how to handle annotations with these cases. I would prefer to get rid of the bug first and to make code as above process without errors. Regards, Bill Pringlemeir. -- I'm not just a gardener, I'm a plant manager. From j.russel.moore at gmail.com Sat Sep 19 04:20:21 2009 From: j.russel.moore at gmail.com (James Russell Moore) Date: Sat, 19 Sep 2009 13:20:21 +0200 Subject: [splint-discuss] Compiling in Windows, MSYS environment. Message-ID: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> Hi I've tried to compile Splint in Windows, in a MSYS environment, it appears to be something missing: make all-recursive make[1]: Entering directory `/d/splint-3.1.2' Making all in src make[2]: Entering directory `/d/splint-3.1.2/src' Compiling cgrammar.c... In file included from cgrammar.c:553:0: Headers/basic.h:17:30: fatal error: ../../winconfig.h: No such file or directory Has anyone come across this? Does anyone know if I'm missing something or how to fix this? Thank you for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090919/a0348e69/attachment.html From splint at sympatico.ca Mon Sep 21 13:11:20 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Mon, 21 Sep 2009 15:11:20 -0500 Subject: [splint-discuss] Compiling in Windows, MSYS environment. In-Reply-To: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> (James Russell Moore's message of "Sat, 19 Sep 2009 13:20:21 +0200") References: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> Message-ID: <87ocp4f47r.fsf@sympatico.ca> A non-text attachment was scrubbed... Name: winconfig.h Type: text/x-chdr Size: 1173 bytes Desc: winconfig.h Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090921/65237721/attachment.bin From splint at sympatico.ca Mon Sep 21 13:11:20 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Mon, 21 Sep 2009 15:11:20 -0500 Subject: [splint-discuss] Compiling in Windows, MSYS environment. In-Reply-To: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> (James Russell Moore's message of "Sat, 19 Sep 2009 13:20:21 +0200") References: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> Message-ID: <87ocp4f47r.fsf@sympatico.ca> A non-text attachment was scrubbed... Name: winconfig.h Type: text/x-chdr Size: 1173 bytes Desc: winconfig.h Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090921/65237721/attachment-0001.bin From Wenzel at bbr-vt.de Mon Sep 21 23:19:47 2009 From: Wenzel at bbr-vt.de (Wenzel, Bodo) Date: Tue, 22 Sep 2009 08:19:47 +0200 Subject: [splint-discuss] Compiling in Windows, MSYS environment. In-Reply-To: <87ocp4f47r.fsf@sympatico.ca> References: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> <87ocp4f47r.fsf@sympatico.ca> Message-ID: <46B6459B655D7342AB97371E8B7CD8B88568F2@sv-exch.BBR.local> > Is it possible > that '../../winconfig.h' can be changed to '..\..\winconfig.h' to see > if the problem changes to some other place? >From my experiences each preprocessor knows how to handle the path separator "/", even on Microsoft systems and preprocessors made by Microsoft. ;-) IMHO it is an error to use "\". If you try you might have to use "\\". Bodo From splint at sympatico.ca Tue Sep 22 09:05:48 2009 From: splint at sympatico.ca (Bill Pringlemeir) Date: Tue, 22 Sep 2009 11:05:48 -0500 Subject: [splint-discuss] Compiling in Windows, MSYS environment. In-Reply-To: <46B6459B655D7342AB97371E8B7CD8B88568F2@sv-exch.BBR.local> (Bodo Wenzel's message of "Tue, 22 Sep 2009 08:19:47 +0200") References: <66a247d10909190420k7014dbe6p9937f53e1ee3c38c@mail.gmail.com> <87ocp4f47r.fsf@sympatico.ca> <46B6459B655D7342AB97371E8B7CD8B88568F2@sv-exch.BBR.local> Message-ID: <87r5tzufqb.fsf@sympatico.ca> On 22 Sep 2009, Wenzel at bbr-vt.de wrote: >> Is it possible >> that '../../winconfig.h' can be changed to '..\..\winconfig.h' to see >> if the problem changes to some other place? > From my experiences each preprocessor knows how to handle the path > separator "/", even on Microsoft systems and preprocessors made by > Microsoft. ;-) > IMHO it is an error to use "\". If you try you might have to use "\\". Yes, thanks it should be a double '\\'. The mingw is different than cygwin in that it does handle '/' as well. Perhaps it is in the scripts instead of the source code... but the output indicated a compiler issue. The OP has not given the compiler they are using. If you know that all Windows compilers do treat the '/' directory separator properly, then that is is not the problem. It was probably related to an include path issue. The OP doesn't seem to reply. I am unsure if there is a FAQ/Readme for Windows compilation. I think there was a PDF or some such. That may have been more helpful information to add to the conversation. I would rather deal with these issues. 1. The CVS repo is currently broken for more current version of the GNU auto tools and doesn't generate proper test builds. 2. For some reason '#line' info is not included in the YACC/Bison output which makes the parser horrific to debug [you can manually fix this, but the depends in the makefile seem to be broken as well which makes it difficult to alter the commands to Bison]. I wonder which platform has a broken YACC and why they couldn't use the pre-packaged output, unless there is some borken compiler that can not deal with it. 3. The CVS access to sourceforge is *SLOW*. It would be much better if this repo was converted to SVN for development. For instance 'cvs diff file.c' might take 5 minutes for me. Regards, Bill Pringlemeir. -- Anyone who trades liberty for security deserves neither liberty nor security - Benjamin Franklin