[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: Tuesday, 23 January, 2007 17:27
> 
> On 1/22/07, Michael Wojcik <Michael.Wojcik at microfocus.com> 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