Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Porting Unix Pro C to NT
A copy of this was sent to Eric Janik <ejanik_at_bi.com>
(if that email address didn't require changing)
On Tue, 16 Feb 1999 20:52:01 GMT, you wrote:
>I'm involved in development effort that requires porting reams of Oracle
>8.0.5 Pro C code to Windows NT. Our most significant stumbling block so far
>has been an anomoly what the Pro C precompiler regards as legal syntax.
>
>Under Unix we declare character string host variables as such:
>
> #define MAXLEN 32
> ...
> EXEC SQL BEGIN DECLARE SECTION;
> char HostCharString[MAXLEN];
> EXEC SQL END DECLARE SECTION;
>
>The NT version of the preprocessor insists that no #defined symbols appear in
>the declare section, so we must indicate the array size with a literal value.
>
> EXEC SQL BEGIN DECLARE SECTION;
> char HostCharString[32];
> EXEC SQL END DECLARE SECTION;
>
>Has anyone dealt with a this sort of problem before, without modifying source
>code? Seriously, modifying source code is NOT an option. We are considering
>writing a preprocessor for the precompiler that de-references macros that
>occur in declare sections. Does such a tool already exist somewhere?
>
The NT port defaults "parse" to "none". On ALL other ports, parse defaults to FULL. Out of the box, proc on NT does not parse C code -- it works like proc 1.6 did. You have to use EXEC BEGIN DECLARE / EXEC SQL END DECLARE, no defines, cannot bind to parameters or records and so on.
If you add:
proc .... parse=FULL ....
to the pro*c command line, proc will behave like proc on Unix does.
>Eric Janik
>
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Service Industries
Reston, VA USA
--
http://govt.us.oracle.com/ -- downloadable utilities
Anti-Anti Spam Msg: if you want an answer emailed to you, you have to make it easy to get email to you. Any bounced email will be treated the same way i treat SPAM-- I delete it. Received on Wed Feb 17 1999 - 08:46:59 CST