Re: Pro*C Variables and Define Tokens
Date: 24 Sep 92 12:02:35 GMT
Message-ID: <19tdtrINNisa_at_matt.ksu.ksu.edu>
lebrun_at_ll.mit.edu (Steven F. LeBrun) writes:
> In article <1992Sep22.175344.5214_at_cbfsb.cb.att.com> gerette_at_cbnewsb.cb.att.com (marianne.g.pittorino) writes:
>>>
>>>I am having trouble declaring Pro*C variables using #define tokens. In my
>>>(UNIX) application, we have an include header file that has #define tokens
>>>for all our data elements. When declaring a 'C' or database variable, we
>>>always use the #define token. For example, if a customer name variable were
>>>needed, we code:
>>>
>>> char custname[CUSTNAME_SZ + 1]; /* add one for NULL byte */
>>>
...
>>>Precompiling x.pc
>>> 20 VARCHAR custname[CUSTNAME_SZ + 1];
>>> 20 ........................^
>>> PCC-S-0018: Expected "<unsigned_integer>", but found "CUSTNAME_SZ" at
>>> line 20 in file x.pc
...
>>> What I cannot believe is that the Pro*C precompiler cannot recognize
>>>#define tokens (and, by the way, it balks at the "+" sign as well). This is
>>>very important to our application; it took many months to standardize all our
>>>code with the #define tokens. Does anyone know how to get this to work?
>>>
>>>
>>>
>>>Marianne
>In article <1992Sep24.121138.6821_at_cs.umb.edu> pytlik_at_ra.cs.umb.edu (Marek Pytlik) writes:
>>To make this work, before precompilation, put the code thru preprocessor. >> >> Mark >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. >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. 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).
>--
>+--------------------------------------------------------------------------+ >| Steven F. LeBrun | MIT Lincoln Laboratory, Group 91 | >| | 244 Wood Street, Room LI-136 | >| lebrun_at_ll.mit.edu (Internet) | Lexington, MA 02173-9108 |>| lebruns_at_merlin (internal) | Phone:(617)-981-5742, FAX:(617)-981-0991 |
+--------------------------------------------------------------------------+ >|"Hard as lightning, soft as candlelight; | >| Dare you trust the Music of the Night?" - The Phantom | >+--------------------------------------------------------------------------+
I ran into the same problem at a company I do consulting for. The solution I came up with was to keep a file called "lengths.h" or some such thing, then have it create, using make, a file called "lengths.m4". All my pc files are actually now named with extension ".m4" and then the main make for the program uses the general Unix preprocessor m4 to create the pc file. Then pro-c runs on this file to create the .c file and cc creates the .o file as usual. It is an extra step in the make, but m4 is very fast.
The reason for having a lengths.h and a lengths.m4 is that sometimes just plain old c files need the lengths definitions. Since you don't want to have to maintain both files, I have lengths.h create lengths.m4 via make.
Works ok, and it was the only way I could think of at the time for having symbolic constants as the lengths for VARCHARS. I also considered writing my own preprocessor, just for this special case, which wouldn't be at all difficult.
--Rick
-- Rick Summerhill Internet: rrsum_at_hermzel.ksu.ksu.edu CNS, Cardwell Hall Bitnet: rrsum_at_ksuvm Kansas State University Phone: (913)532-6311 Manhattan, KS 66506 FAX: (913)532-5914Received on Thu Sep 24 1992 - 14:02:35 CEST