From Keith.Richeson at us.elster.com Fri Jan 19 06:11:35 2007 From: Keith.Richeson at us.elster.com (Keith.Richeson@us.elster.com) Date: Fri Jan 19 06:18:59 2007 Subject: [splint-discuss] Parse error with @ from the IAR compiler Message-ID: Hello all, I'm sorry if this has already been discussed, but I searched the archive back through the past year and was not able to find any related information. I'm working on an embedded project and we are using the IAR C compiler for the 8051. One of the extensions to the compiler is that it allows a user to "locate" a variable using the @ symbol. That is to say, if I want to make sure that a variable gets allocated at location 0xFFE0 in RAM, I can use the following declaration: int myVar @ 0xFFE0; and the compiler will understand the statement. Of course since this is not standard C splint is not happy with the above statement, and in fact a parse error is generated so using /*@ignore@*/ doesn't help. My first idea of how to deal with this is to define @ = "; //" so that the line effectively ends at the @ symbol and everything else is a comment. Unfortunately when I add the following line to my .lclintrc file: -D@="; //" I get the following message from splint: Splint 3.1.1 --- 12 April 2003 Command Line: Malformed option `-D@='"; //"'' Preprocessing error. (Use -preproc to inhibit warning) Preprocessing error for file: assert.c *** Cannot continue. Is there something I need to do to escape the @ symbol in the .lclintrc file? Does anyone have any other suggestions for getting around this issue? Thanks!!! Keith Richeson (919) 250-5511 keith.richeson@us.elster.com "A problem well stated is a problem half solved" From Michael.Wojcik at MicroFocus.com Fri Jan 19 06:54:45 2007 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Fri Jan 19 06:56:45 2007 Subject: [splint-discuss] Parse error with @ from the IAR compiler In-Reply-To: Message-ID: <11352F9641010A418AD5057945A3A6598B3E52@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Keith.Richeson@us.elster.com > Sent: Friday, 19 January, 2007 09:12 > Subject: [splint-discuss] Parse error with @ from the IAR compiler > > > > I'm working on an embedded project and we are using the IAR C compiler for > the 8051. One of the extensions to the compiler is that it allows a user > to "locate" a variable using the @ symbol. That is to say, if I want to > make sure that a variable gets allocated at location 0xFFE0 in RAM, I can > use the following declaration: > > int myVar @ 0xFFE0; > > and the compiler will understand the statement. > > Of course since this is not standard C splint is not happy with the above > statement, and in fact a parse error is generated... As it should be. "@" isn't even part of the basic source character set defined by ISO 9899; no C implementation is required to translate a source file containing it. > My first idea of how to deal with this is to define @ = "; > //" so that the line effectively ends at the @ symbol and everything else > is a comment. I'll note in passing that prior to C99, "//" wasn't a part of standard C either. The real problem, though, is that "@", not being part of the source character set, can't be used in an identifier, either, and macro names are identifiers. > Does anyone have any other suggestions for getting around this > issue? I'd wrap the compiler's special syntax in a macro, then conditionally-compile it for Splint: #if defined S_SPLINT_S #define VAR_AT(addr) #else #define VAR_AT(addr) @ addr #endif and then in your code, replace all int myVar @ 0xFFE0; with int myVar VAR_AT(0xFFE0); Of course, that may be more work than what you want to do. Another alternative would be to stick a filter into your toolchain in front of Splint that removes all the @-expressions; that's pretty trivial if they're all consistently formatted with the address on the same line as the operator. With sed, for example: sed "s/@[^,;]*//g" source.c > source-tmp.c splint source-tmp.c Details depend on what tools you have available, but this this is easy to do on Unix, and pretty easy on Windows with the addition of some free software. -- Michael Wojcik 517 676-0892 Software Systems Developer Micro Focus http://www.microfocus.com/ From beroset at mindspring.com Fri Jan 19 08:53:51 2007 From: beroset at mindspring.com (Ed Beroset) Date: Fri Jan 19 10:24:36 2007 Subject: [splint-discuss] Parse error with @ from the IAR compiler Message-ID: <10193083.1169225631200.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Keith.Richeson@us.elster.com wrote: >I'm working on an embedded project and we are using the IAR C compiler for >the 8051. One of the extensions to the compiler is that it allows a user >to "locate" a variable using the @ symbol. That is to say, if I want to >make sure that a variable gets allocated at location 0xFFE0 in RAM, I can >use the following declaration: > >int myVar @ 0xFFE0; I think that compiler also has a #pragma location=xxx that you could use instead. That way the compiler is happy and splint will work. #pragma location=0xffe0 int myVar; Ed From Keith.Richeson at us.elster.com Fri Jan 19 10:37:13 2007 From: Keith.Richeson at us.elster.com (Keith.Richeson@us.elster.com) Date: Fri Jan 19 10:44:37 2007 Subject: [splint-discuss] Parse error with @ from the IAR compiler In-Reply-To: <11352F9641010A418AD5057945A3A6598B3E52@MTV-EXCHANGE.microfocus.com> Message-ID: Mr. Wojcik, Thank you for your recommendations. I had not thought about using sed to accomplish basically the same thing I am trying to do with the -D option. I will cetainly look into that. Thanks!!! Keith Richeson (919) 250-5511 keith.richeson@us.elster.com "A problem well stated is a problem half solved" "Michael Wojcik" To Sent by: "Discussions about the Splint splint-discuss-bo annotation-assisted static unces@cs.virginia analysisproject" .edu cc 01/19/2007 11:51 Subject AM RE: [splint-discuss] Parse error with @ from the IAR compiler Please respond to Discussions about the Splint annotation-assist ed static analysis project > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Keith.Richeson@us.elster.com > Sent: Friday, 19 January, 2007 09:12 > Subject: [splint-discuss] Parse error with @ from the IAR compiler > > > > I'm working on an embedded project and we are using the IAR C compiler for > the 8051. One of the extensions to the compiler is that it allows a user > to "locate" a variable using the @ symbol. That is to say, if I want to > make sure that a variable gets allocated at location 0xFFE0 in RAM, I can > use the following declaration: > > int myVar @ 0xFFE0; > > and the compiler will understand the statement. > > Of course since this is not standard C splint is not happy with the above > statement, and in fact a parse error is generated... As it should be. "@" isn't even part of the basic source character set defined by ISO 9899; no C implementation is required to translate a source file containing it. > My first idea of how to deal with this is to define @ = "; > //" so that the line effectively ends at the @ symbol and everything else > is a comment. I'll note in passing that prior to C99, "//" wasn't a part of standard C either. The real problem, though, is that "@", not being part of the source character set, can't be used in an identifier, either, and macro names are identifiers. > Does anyone have any other suggestions for getting around this > issue? I'd wrap the compiler's special syntax in a macro, then conditionally-compile it for Splint: #if defined S_SPLINT_S #define VAR_AT(addr) #else #define VAR_AT(addr) @ addr #endif and then in your code, replace all int myVar @ 0xFFE0; with int myVar VAR_AT(0xFFE0); Of course, that may be more work than what you want to do. Another alternative would be to stick a filter into your toolchain in front of Splint that removes all the @-expressions; that's pretty trivial if they're all consistently formatted with the address on the same line as the operator. With sed, for example: sed "s/@[^,;]*//g" source.c > source-tmp.c splint source-tmp.c Details depend on what tools you have available, but this this is easy to do on Unix, and pretty easy on Windows with the addition of some free software. -- Michael Wojcik 517 676-0892 Software Systems Developer Micro Focus http://www.microfocus.com/ _______________________________________________ splint-discuss mailing list splint-discuss@ares.cs.Virginia.EDU http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss ______________________________________________________________________ This email has been spam and virus checked by Elster IT Services. From prlawrence at gmail.com Mon Jan 22 09:56:53 2007 From: prlawrence at gmail.com (Phil Lawrence) Date: Mon Jan 22 09:57:09 2007 Subject: [splint-discuss] checking Oracle Pro*C files Message-ID: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> Hello, I'm fairly new to C and am working with Oracle Pro*C. This means my source files have items for the Oracle preprocessor like this in it: EXEC SQL INCLUDE sqlca; EXEC SQL BEGIN DECLARE SECTION; VARCHAR sqli_inputAccount[15]; EXEC SQL END DECLARE SECTION; How can I have splint ignore these things? I had the bright idea that I could just run my .pc files through the Oracle preprocessor and then splint the resulting .c file... That seemed to work (splint did start talking about my .c file), but then splint said it was back to checking the .pc file (see output copied below). Why? $ splint ~/Volumes/11/src/dcv_ex_account_table.c Splint 3.1.1 --- 22 Jan 2007 ../../../Volumes/11/src/dcv_ex_account_table.c:41:32: Initializer block for sqladt has 3 fields, but struct sqladts has 4 fields: 1, 1, 0 Initializer does not set every field in the structure. (Use -fullinitblock to inhibit warning) ../../../Volumes/11/src/dcv_ex_account_table.c:54:1: Initializer block for sqltds has 2 fields, but struct sqltdss has 3 fields: 1, 0 ../../../Volumes/11/src/dcv_ex_account_table.c:114:12: Initializer block for sqlstm has 2 fields, but struct sqlexd has 38 fields: 12, 42 dcv_ex_account_table.pc: (in function dcv_openCursorExAccountTable) dcv_ex_account_table.pc:52:10: Parameter 1 (db_name) to function strcpy is declared unique but may be aliased externally by parameter 2 (i_db_name) A unique or only parameter may be aliased by some other parameter or visible global. (Use -mayaliasunique to inhibit warning) dcv_ex_account_table.pc:56:7: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. How should I use splint to help me with these Pro*C source files? Thanks, Phil Lawrence From lholzheid at bihl-wiedemann.de Mon Jan 22 10:30:59 2007 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon Jan 22 10:36:06 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> References: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> Message-ID: <20070122183059.GA4139@svr5.bihl-wiedemann.de> On Mon, 2007-01-22 11:56:53 -0600, Phil Lawrence wrote: > [..] > I had the bright idea that I could just run my .pc files through the > Oracle preprocessor and then splint the resulting .c file... That > seemed to work (splint did start talking about my .c file), but then > splint said it was back to checking the .pc file (see output copied > below). Why? Hello Phil, I suppose your preprocessor includes "#line" directives to its output, including the original file name. If this is the case, splint is able to determine the original error locations and uses these for messages instead of the line numbers in the generated .c file. (The compilers do the same.) I have no idea what's "Oracle Pro*C" about and how much work this would be, but I suppose it was better to have a set of #defines (or -D options to splint) and let split's preprocessor replace the "EXEC SQL ..." statements by some C compatible syntax. That way, splint was able to distinguish between system and user headers, use prototypes for C macros, and so on. Particularly, if your preprocessor removes the comments, you lose the possibility for code annotations. Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From Michael.Wojcik at MicroFocus.com Mon Jan 22 12:06:10 2007 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Mon Jan 22 12:07:19 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> Message-ID: <11352F9641010A418AD5057945A3A6598B3E5F@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Phil Lawrence > Sent: Monday, 22 January, 2007 12:57 > > I'm fairly new to C and am working with Oracle Pro*C. This means my > source files have items for the Oracle preprocessor like this in it: > EXEC SQL INCLUDE sqlca; > EXEC SQL BEGIN DECLARE SECTION; > VARCHAR sqli_inputAccount[15]; > EXEC SQL END DECLARE SECTION; > > How can I have splint ignore these things? Suppress the EXEC SQL statements for the Splint run: #if !defined S_SPLINT_S EXEC SQL ... #endif > I had the bright idea that I could just run my .pc files through the > Oracle preprocessor and then splint the resulting .c file... That > seemed to work (splint did start talking about my .c file), but then > splint said it was back to checking the .pc file (see output copied > below). It's not; it's still checking the generated .c file. The .c file contains #line directives that tell Splint the name of the file that it was generated from, however, and that's what Splint will report to you, since it's generally more useful for the user. > $ splint ~/Volumes/11/src/dcv_ex_account_table.c > Splint 3.1.1 --- 22 Jan 2007 > > ../../../Volumes/11/src/dcv_ex_account_table.c:41:32: > Initializer block for sqladt has 3 fields, but struct sqladts has 4 fields: > 1, 1, 0 > Initializer does not set every field in the structure. (Use -fullinitblock to > inhibit warning) You'll get these sorts of warnings from code generated by Pro*C because it uses constructs that are well-defined in C but that Splint believes could indicate programmer error. Here, for example, the missing initializer is automatically treated as if it were "{0}" - the C standard defines this behavior - but Splint warns you about it in case you accidentally omitted an initializer. If you used this idiom deliberately in your own code, you could suppress this Splint warning with a code annotation, or globally by setting an option. But running the code through Pro*C would discard any Splint annotations (because they're comments). You really don't want to preprocess and then use Splint. That will cripple a number of Splint features (code annotations, recognition of standard headers, etc). Instead, suppress the EXEC SQL statements when Splint is running, as I described above. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From Michael.Wojcik at MicroFocus.com Mon Jan 22 12:06:10 2007 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Mon Jan 22 12:12:26 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> Message-ID: <11352F9641010A418AD5057945A3A6598B3E5F@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Phil Lawrence > Sent: Monday, 22 January, 2007 12:57 > > I'm fairly new to C and am working with Oracle Pro*C. This means my > source files have items for the Oracle preprocessor like this in it: > EXEC SQL INCLUDE sqlca; > EXEC SQL BEGIN DECLARE SECTION; > VARCHAR sqli_inputAccount[15]; > EXEC SQL END DECLARE SECTION; > > How can I have splint ignore these things? Suppress the EXEC SQL statements for the Splint run: #if !defined S_SPLINT_S EXEC SQL ... #endif > I had the bright idea that I could just run my .pc files through the > Oracle preprocessor and then splint the resulting .c file... That > seemed to work (splint did start talking about my .c file), but then > splint said it was back to checking the .pc file (see output copied > below). It's not; it's still checking the generated .c file. The .c file contains #line directives that tell Splint the name of the file that it was generated from, however, and that's what Splint will report to you, since it's generally more useful for the user. > $ splint ~/Volumes/11/src/dcv_ex_account_table.c > Splint 3.1.1 --- 22 Jan 2007 > > ../../../Volumes/11/src/dcv_ex_account_table.c:41:32: > Initializer block for sqladt has 3 fields, but struct sqladts has 4 fields: > 1, 1, 0 > Initializer does not set every field in the structure. (Use -fullinitblock to > inhibit warning) You'll get these sorts of warnings from code generated by Pro*C because it uses constructs that are well-defined in C but that Splint believes could indicate programmer error. Here, for example, the missing initializer is automatically treated as if it were "{0}" - the C standard defines this behavior - but Splint warns you about it in case you accidentally omitted an initializer. If you used this idiom deliberately in your own code, you could suppress this Splint warning with a code annotation, or globally by setting an option. But running the code through Pro*C would discard any Splint annotations (because they're comments). You really don't want to preprocess and then use Splint. That will cripple a number of Splint features (code annotations, recognition of standard headers, etc). Instead, suppress the EXEC SQL statements when Splint is running, as I described above. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From prlawrence at gmail.com Tue Jan 23 14:26:35 2007 From: prlawrence at gmail.com (Phil Lawrence) Date: Tue Jan 23 14:27:01 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <11352F9641010A418AD5057945A3A6598B3E5F@MTV-EXCHANGE.microfocus.com> References: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> <11352F9641010A418AD5057945A3A6598B3E5F@MTV-EXCHANGE.microfocus.com> Message-ID: <530ac78e0701231426r758561d0mf93db6a996224fa7@mail.gmail.com> On 1/22/07, Michael Wojcik wrote: > You really don't want to preprocess and then use Splint. That will > cripple a number of Splint features (code annotations, recognition of > standard headers, etc). Instead, suppress the EXEC SQL statements when > Splint is running, as I described above. OK, I understand how I lose functionality by running against the preprocessed source. Still, help me understand this: I preprocess the file, which means (AFAIK) that all the super Oracle syntax is turned into valid c. So here's a parse error from splint on my preprocessed file: dcv_ex_account_table.pc:56:7: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. Here's the relevant section from the preprocessed source: 420 long dcv_openCursorExAccountTable(char *i_db_name, char * i_accountNumber) 421 { 422 strcpy(db_name, i_db_name); 423 424 /* EXEC SQL BEGIN DECLARE SECTION; */ 425 #line 54 "dcv_ex_account_table.pc" 426 427 /* VARCHAR sqli_inputAccount[15]; */ 428 struct { unsigned short len; unsigned char arr[15]; } sqli_inputAccount; 429 #line 55 "dcv_ex_account_table.pc" 430 431 /* EXEC SQL END DECLARE SECTION; */ 432 #line 56 "dcv_ex_account_table.pc" 433 434 435 memcpy(sqli_inputAccount.arr,i_accountNumber,15); 436 sqli_inputAccount.len = 15; 437 What is causing the parse error? It's not the 'EXEC SQL...' stuff, because that's now in a comment, right? Is it the memcpy line? Thanks, Phil From Michael.Wojcik at MicroFocus.com Tue Jan 23 15:08:11 2007 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Tue Jan 23 15:09:09 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <530ac78e0701231426r758561d0mf93db6a996224fa7@mail.gmail.com> Message-ID: <11352F9641010A418AD5057945A3A6598B3E71@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Phil Lawrence > Sent: Tuesday, 23 January, 2007 17:27 > > On 1/22/07, Michael Wojcik wrote: > > > You really don't want to preprocess and then use Splint. > > OK, I understand how I lose functionality by running against the > preprocessed source. > > Still, help me understand this: > I preprocess the file, which means (AFAIK) that all the super Oracle > syntax is turned into valid c. If only it were so... > So here's a parse error from splint on my preprocessed file: > > dcv_ex_account_table.pc:56:7: Parse Error. (For help on parse errors, see > splint -help parseerrors.) > *** Cannot continue. > > Here's the relevant section from the preprocessed source: > 420 long dcv_openCursorExAccountTable(char *i_db_name, char *i_accountNumber) > 421 { > 422 strcpy(db_name, i_db_name); > 423 > 424 /* EXEC SQL BEGIN DECLARE SECTION; */ > 425 #line 54 "dcv_ex_account_table.pc" > 426 > 427 /* VARCHAR sqli_inputAccount[15]; */ > 428 struct { unsigned short len; unsigned char arr[15]; } > sqli_inputAccount; That's not legal C, prior to C99 (which Splint does not support). Declarations have to appear before statements in C, but Pro*C has a statement (the strcpy on line 422) followed by a declaration (for sqli_inputAccount on line 428). C99 (ISO 9899-1999) relaxed that rule and allowed intermixed statements and declarations in a block, because C++ does and many C implementations allowed it as an extension, but prior to C99 it's non-conforming. You could actually fix this by wrapping the EXEC SQL statement in a block, in the original .pc source file: strcpy(db_name, i_db_name); { EXEC SQL ... } so that any declarations created by Pro*C would be at the beginning of that new block. That's assuming Pro*C isn't just generating interleaved statements and declarations willy-nilly for a single EXEC SQL statement, which it might be, for all I know; and that you don't need to refer to any of the identifiers declared by code generated by Pro*C later. I've never worked with Pro*C myself, so I really don't know how successful that would be. I've used embedded SQL in COBOL, but the rules there are very different. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From lholzheid at bihl-wiedemann.de Tue Jan 23 15:13:59 2007 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Tue Jan 23 15:14:14 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <530ac78e0701231426r758561d0mf93db6a996224fa7@mail.gmail.com> References: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> <11352F9641010A418AD5057945A3A6598B3E5F@MTV-EXCHANGE.microfocus.com> <530ac78e0701231426r758561d0mf93db6a996224fa7@mail.gmail.com> Message-ID: <20070123231359.GA8170@svr5.bihl-wiedemann.de> On Tue, 2007-01-23 16:26:35 -0600, Phil Lawrence wrote: > [..] > > dcv_ex_account_table.pc:56:7: Parse Error. (For help on parse errors, see > splint -help parseerrors.) > *** Cannot continue. > > Here's the relevant section from the preprocessed source: > 420 long dcv_openCursorExAccountTable(char *i_db_name, char * > i_accountNumber) > 421 { > 422 strcpy(db_name, i_db_name); > 423 > 424 /* EXEC SQL BEGIN DECLARE SECTION; */ > 425 #line 54 "dcv_ex_account_table.pc" > 426 > 427 /* VARCHAR sqli_inputAccount[15]; */ > 428 struct { unsigned short len; unsigned char arr[15]; } > sqli_inputAccount; > 429 #line 55 "dcv_ex_account_table.pc" > 430 > 431 /* EXEC SQL END DECLARE SECTION; */ > 432 #line 56 "dcv_ex_account_table.pc" > 433 > 434 > 435 memcpy(sqli_inputAccount.arr,i_accountNumber,15); > 436 sqli_inputAccount.len = 15; > 437 > > What is causing the parse error? It's not the 'EXEC SQL...' stuff, > because that's now in a comment, right? Is it the memcpy line? Hello Phil, splint chokes on line 428 of the preprocessor output, or line 56 (54 +2) of dcv_ex_account_table.pc, respectively. The problem with this line is, this is a declaration following a statement. This is not allowed in ANSI C89/ISO C90 and splint's parser is not able to parse this. There have been wishes to update the parser to support C99, but nobody volunteered. Maybe you could change the "EXEC SQL BEGIN DECLARE SECTION" to a opening brace (and insert a closing brace somewhere below). I'm afraid checking your "Oracle Pro*C" files is going to get tricky. Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From lholzheid at bihl-wiedemann.de Tue Jan 23 15:13:59 2007 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Tue Jan 23 15:16:19 2007 Subject: [splint-discuss] checking Oracle Pro*C files In-Reply-To: <530ac78e0701231426r758561d0mf93db6a996224fa7@mail.gmail.com> References: <530ac78e0701220956y37ca5edahc7260ea9a2368af@mail.gmail.com> <11352F9641010A418AD5057945A3A6598B3E5F@MTV-EXCHANGE.microfocus.com> <530ac78e0701231426r758561d0mf93db6a996224fa7@mail.gmail.com> Message-ID: <20070123231359.GA8170@svr5.bihl-wiedemann.de> On Tue, 2007-01-23 16:26:35 -0600, Phil Lawrence wrote: > [..] > > dcv_ex_account_table.pc:56:7: Parse Error. (For help on parse errors, see > splint -help parseerrors.) > *** Cannot continue. > > Here's the relevant section from the preprocessed source: > 420 long dcv_openCursorExAccountTable(char *i_db_name, char * > i_accountNumber) > 421 { > 422 strcpy(db_name, i_db_name); > 423 > 424 /* EXEC SQL BEGIN DECLARE SECTION; */ > 425 #line 54 "dcv_ex_account_table.pc" > 426 > 427 /* VARCHAR sqli_inputAccount[15]; */ > 428 struct { unsigned short len; unsigned char arr[15]; } > sqli_inputAccount; > 429 #line 55 "dcv_ex_account_table.pc" > 430 > 431 /* EXEC SQL END DECLARE SECTION; */ > 432 #line 56 "dcv_ex_account_table.pc" > 433 > 434 > 435 memcpy(sqli_inputAccount.arr,i_accountNumber,15); > 436 sqli_inputAccount.len = 15; > 437 > > What is causing the parse error? It's not the 'EXEC SQL...' stuff, > because that's now in a comment, right? Is it the memcpy line? Hello Phil, splint chokes on line 428 of the preprocessor output, or line 56 (54 +2) of dcv_ex_account_table.pc, respectively. The problem with this line is, this is a declaration following a statement. This is not allowed in ANSI C89/ISO C90 and splint's parser is not able to parse this. There have been wishes to update the parser to support C99, but nobody volunteered. Maybe you could change the "EXEC SQL BEGIN DECLARE SECTION" to a opening brace (and insert a closing brace somewhere below). I'm afraid checking your "Oracle Pro*C" files is going to get tricky. Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From timir at domestech.com Tue Jan 23 17:42:54 2007 From: timir at domestech.com (Timir Karia) Date: Tue Jan 23 17:50:11 2007 Subject: [splint-discuss] unsubsrcibe Message-ID: -- Timir Karia Domestech, Inc. timir@domestech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20070123/a384820a/attachment.htm From tsuneo.yoshioka at f-secure.com Sun Jan 28 22:02:28 2007 From: tsuneo.yoshioka at f-secure.com (Yoshioka Tsuneo) Date: Sun Jan 28 22:30:08 2007 Subject: [splint-discuss] Parse Error on siginfo_t Message-ID: <20070129145445.C8AC.TSUNEO.YOSHIOKA@f-secure.com> Hello Thank you very much for providing nice software to build secure software. Well, I just tried to use splint. But, I got Parse Error on siginfo_t. I just tried to add "+posixlib" or "posixstrictlib", but this does not solve the issue. Can I get any information to avoid this error ? Command result and test code is below. I have tested using splint 3.1.1 on RedHat EL3.0. (I got the same result on RedHat EL4.0, too.) Command Result: ========================================================================== # splint sigtest1.c Splint 3.1.1 --- 26 Jan 2007 sigtest1.c:2: Include file matches the name of a POSIX library, but the POSIX library is not being used. Consider using +posixlib or +posixstrictlib to select the POSIX library, or -warnposix to suppress this message. Header name matches a POSIX header, but the POSIX library is not selected. (Use -warnposixheaders to inhibit warning) sigtest1.c:8:39: Parse Error: Inconsistent function parameter syntax: siginfo_t : . (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. # splint +posixlib sigtest1.c Splint 3.1.1 --- 26 Jan 2007 sigtest1.c:8:39: Parse Error: Inconsistent function parameter syntax: siginfo_t : . (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. # splint +posixstrictlib sigtest1.c Splint 3.1.1 --- 26 Jan 2007 sigtest1.c:8:39: Parse Error: Inconsistent function parameter syntax: siginfo_t : . (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. ============================================================================= Test code(sigtest1.c) ============================================================================= #include #include #include #include #include void signal_handler(int sig, siginfo_t *info, void *context) { printf("sig=%d, si_code=%d, si_pid=%d\n" , info->si_signo, info->si_code, info->si_pid); alarm(1); } int main(int argc, char *argv[]) { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_sigaction = signal_handler; sa.sa_flags |= (SA_RESTART|SA_SIGINFO); sigemptyset(&sa.sa_mask); sigaddset(&sa.sa_mask, SIGALRM); sigaction(SIGALRM, &sa, NULL); alarm(1); while(1){sleep(1);} return 0; } ============================================================================= Thank you. -- Nihon F-Secure Corporation Yoshioka Tsuneo E-MAIL: Tsuneo.Yoshioka@f-secure.com From lholzheid at bihl-wiedemann.de Mon Jan 29 14:31:34 2007 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon Jan 29 14:31:58 2007 Subject: [splint-discuss] Parse Error on siginfo_t In-Reply-To: <20070129145445.C8AC.TSUNEO.YOSHIOKA@f-secure.com> References: <20070129145445.C8AC.TSUNEO.YOSHIOKA@f-secure.com> Message-ID: <20070129223134.GC16823@svr5.bihl-wiedemann.de> On Mon, 2007-01-29 15:02:28 +0900, Yoshioka Tsuneo wrote: > [..] > Well, I just tried to use splint. > But, I got Parse Error on siginfo_t. I just tried to add "+posixlib" or > "posixstrictlib", but this does not solve the issue. > Can I get any information to avoid this error ? Hello Tsuneo, your problem is, the sources you are trying to process with splint use features introduced by IEEE Std 1003.1b-1993, whereas split knows about the POSIX specification IEEE 1003.1-1990 only. The clean solution would be to update posix.h and re-generate posix(strict).lcd. As a quick-and-dirty solution, you could provide a dummy definition for siginfo_t and hide it from the compiler by enclosing it in preprocessor directives: #if defined (S_SPLINT_S) typedef struct { int si_signo; int si_code; pid_t si_pid; } siginfo_t; #endif Note, splint will still complain about the sa_sigaction member of struct sigaction, as this seems to be new in IEEE Std 1003.1b-1993. HTH, Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From tsuneo.yoshioka at f-secure.com Tue Jan 30 03:22:48 2007 From: tsuneo.yoshioka at f-secure.com (Yoshioka Tsuneo) Date: Tue Jan 30 03:23:07 2007 Subject: [splint-discuss] Parse Error on siginfo_t In-Reply-To: <20070129223134.GC16823@svr5.bihl-wiedemann.de> References: <20070129145445.C8AC.TSUNEO.YOSHIOKA@f-secure.com> <20070129223134.GC16823@svr5.bihl-wiedemann.de> Message-ID: <20070130201832.A876.TSUNEO.YOSHIOKA@f-secure.com> Hello Ludolf-san Thank you for your information. While this error seems be solved for about "siginfo_t", other error seems happens for other structures(ex: sa_sigaction as you wrote). I'll think whether I can use splint for the target software. Thank you ! -- Nihon F-Secure Corporation Yoshioka Tsuneo E-MAIL: Tsuneo.Yoshioka@f-secure.com