Hi,
I have a large amount of legacy C code that contains embedded SQL
statements. One header file contains lots of type definitions and is
included in many places via EXEC SQL INCLUDE 'file.h' statements.

There is now a requirement to make some of the string sizes dependent
on a compiler define, for example:

#ifdef BIG_STRING
#define STRING_LEN 256
#else
#define STRING_LEN 80
#endif

typedef struct {
...
char data[STRING_LEN];
...

The ESQLC preprocessor cannot cope with the #ifdef's. Does anyone
have a simple workaround for this kind of problem? i.e. One that
does not involve splitting the header file up which would result in
changes to 100's of source files.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.]

On Oct 16, 2009, at 3:51 AM, Mark wrote:


What version are you running? This sort of thing works for me,
although a
wee bit of command line trickery may be needed.

x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
exec sql begin declare section;
char buf[LEN];
exec sql end declare section;

-----
x.sc:
exec sql include 'x.h';
main(){}
----
esqlc -o.ch x.sc
creates an x.c that includes x.ch

cc -DBIG_STRING -o x x.c
works for me.

The -o.xx says write preprocessed exec-sql-include files with
the extension xx. (The -o flag by itself says don't output the
preprocessed include file, in the case where it's done elsewhere.)

If this isn't what you are after, please give us more details about
how the includes are set up, how you are running the pre-
processor, what version, and where BIG_STRING is defined.

Karl

On Fri, 16 Oct 2009 08:10:35 -0400, Karl Schendel
<schendel (AT) kbcomputer (DOT) com> wrote:

Didn't see your post until now 'cos the subject had changed.

Ingres 2 v 2.6/0305

Our situation is a little different. The header file in question has
to be included in non-esqlc (plain C) code so we do the following
(based on your example):

x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
char buf[LEN];
-----
x.sc:
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
main(){}
----

E_EQ0244 Syntax error in 'ifdef'.

--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.]

On Oct 20, 2009, at 6:17 AM, Mark wrote:


I see, it's because the header is inside an exec sql declare
section surrounding the include. It would work otherwise.

I can't think of any simple way to deal with this, unless the header
can be preprocessed by itself more or less standalone. Then you
could rename the header, cpp it with the output being its current
name, and the result should work inside the declare section.

Another alternative that is more work would be to extract all
of the #ifdef / #define stuff into a separate header, and include
that header outside of the esqlc declare section. If you did
something like:
defines.h:
#ifndef DEFINE_H_INCLUDED
#define DEFINE_H_INCLUDED
#ifdef BIG_STRING
.... etc
#endif /* DEFINE_H_INCLUDED */

x.h:
#include <defines.h>
char buf[LEN];

x.sc:
#include <defines.h>
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;

I think that would work (haven't tested it though), and it would mean
that you would only have to change your esqlc files and not your
other .c files.

Karl

With the downside that it might complicate the build pipeline there is
always the possibility of passing some of your files through the C
preprocessor step (only) before the esqlc step. So it would be:
preprocess (a file subset) -> esqlc -> ( preprocess -> compile ->
link )

MikeT

On Oct 20, 10:51*am, Karl Schendel <schen... (AT) kbcomputer (DOT) com> wrote:

On Tue, 20 Oct 2009 10:51:36 -0400, Karl Schendel
<schendel (AT) kbcomputer (DOT) com> wrote:

I had thought of this solution but would rather avoid it as it would
be difficult to support on all the platforms that this software needs
to work on.

This is the other solution I was trying to avoid ;-) It is slightly
more complex than this since our BIG_STRING (LEN) #define is sometimes
used in ESQL code.

I think I will just have to bite the bullet and implement the latter
solution.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.]