[splint-discuss] checking Oracle Pro*C files

[Michael Wojcik]

> From: splint-discuss-bounces at cs.virginia.edu 
> [mailto:splint-discuss-bounces at 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