Re: Pro*C Variables and Define Tokens

In article <9209241219.PN26301_at_LL.MIT.EDU> lebrun_at_ll.mit.edu (Steven F. LeBrun) writes:
>Unfortunately, running Pro*C code through the preprocessor before running
>it throught the Pro*C precompiler can results in problems. Remember that
>in C, NULL is a macro. In Embedded SQL, NULL is a keyword.
>
>Running Pro*C code through a preprocessor will result in all SQL NULL's
>being translated into to your local C definition of the macro NULL which
>will not be a NULL to SQL.

True. That is why with Pro*C 2.0 SQL statements are scanned differently than C and precompiler statements. So NULL (or null) in a SQL statement will not get clobbered, but will be substituted in C or precompiler stuff.

>Also, considering that the Pro*C precompiler is really just making text
>substitution (One Embedded SQL Statement into a set of C code) I do not
>understand why the precompiler requires a numeric literal (constant)
>where a macro constant should suffice. If you look at the C code
>generated by the Pro*C precompiler, it just plugs in the numbers it
>gets from expressions like `VARCHAR xxx[123]' directly into
>function calls and variable definitions.

The precompiler needs to know the size of the VARCHAR, there are limits.

> I always got the impression,
>when dealing with Pro*C precompiler, that I was working with a program
>that is treating C code as if it was FORTRAN (pre parameter statement
>Fortran).

Hmm... In Oracle's defense, we do supply (and support, and document) precompilers for six languages, in 3 different versions. Right now I have about 21 precompiler and OCI manuals consuming about 50MB of disk space. Version 1.4 and 1.5 code gen is much improved, and Version 2.0 (C only) will be another very big improvement.

--Tim (tssmith_at_oracle.com) (RDBMS Marketing--Languages Documentation) Received on Fri Sep 25 1992 - 04:40:34 CEST