Re: pro*C parser bug?

In article <784166109snz_at_sambusys.demon.co.uk>, psb_at_sambusys.demon.co.uk (Paul Beardsell) writes:
|> In article <39gqur$mq6_at_tequesta.gate.net> gnd_at_gate.net "Gregory Dora" writes:
|>
|> > Why does my pro*c precompiler change a VARCHAR declaration?
|> >
|> > It turns VARCHAR foo[5000][12]; from the .pc source to
|> > struct
|> > {
|> > char arr[14];
|> > int len;
|> > }foo [5000];
|> > in the generated .c file.
|> >
|> > I must have 30 VARCHARS it parses right, but this one it messes up.
|> > The .c code shows the unparsed VARCHAR foo[5000][12] in the comments
|> > but messes up the code it generates. Has anyone else had this
|> > problem?
|> >
|> > I am doing a port from a Motorola box running Oracle 6x and Unix to a
|> > HP running Oracle 7x and Unix.
|> >
|> > Thank You,
|> > Greg Dora
|> > gnd_at_hopi.gate.net or
|> > gdora_at_pts.mot.com
|>
|> Perhaps Pro*C is deciding to have each element of the array start on
|> a 4 byte boundary?
|>
|> --
|> Paul Beardsell SAM Business Systems Ltd
|> ~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
|> pbeardsell_at_cix.compulink.co.uk London, N1-6BN, UK.
|> psb_at_sambusys.demon.co.uk (+44 or 0)71 608-2391

This is pretty much the case. The Pro*C 1.6 manual documents a new sqllib function (which I believe is also available in the 1.5 library). It's called sqlvcp(), and will tell you the total actual length (including the 2 bytes for the size) given the declared length:

int sqlvcp(long *datlen, long *totlen)

In your case, passing 12 for datlen would return 16 for totlen, indicating that the precompiler will be expanding the varchar declaration by 2 bytes to align it on a word boundary. Received on Mon Nov 07 1994 - 18:24:33 CET