Problem with Pro*c

[empriser]

#define XLOG( ... ) \
do{ \
sprintf( SysBuf, "[%s][%s/%d/%s] ", curtime(), __FILE__ ,
__LINE__ , __FUNCTION__ ); \
sprintf( SysBuf + strlen( SysBuf ), __VA_ARGS__ ); \
xlog( SysBuf ); \
}while(0)


I compile the with Pro*c, but it gave me the error message... ,
however, it's totally correct with gcc. How can solve the problem
the proc error message：

Syntax error at line 27, column 15, file ../comm/comm.h:
Error at line 27, column 15 in file ../comm/comm.h
#define XLOG( ... ) \
...............1
PCC-S-02014, Encountered the symbol "..." when expecting one of the
following:

) an identifier, define, elif, else, endif, error, if, ifdef,
ifndef, include, line, pragma, undef, exec, sql, begin, end,
var, type, oracle, an immediate preprocessor command,
a C token, create, function, package, procedure, trigger, or,
replace,
The symbol ")" was substituted for "..." to continue.

 

[Erik de Castro Lopo]

Syntax error at line 27, column 15, file ../comm/comm.h:
Error at line 27, column 15 in file ../comm/comm.h
#define XLOG( ... )

Try removing the spaces on either side of the "...." to make

#define XLOG(...)

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
The difference between genius and stupidity is that
genius has its limits.

 

[Ian Collins]

#define XLOG( ... ) \

Is this compiler a C99 compiler? variadic macros were introduced in C99.

 

[Richard Heathfield]

empriser said:

#define XLOG( ... ) \
do{ \
sprintf( SysBuf, "[%s][%s/%d/%s] ", curtime(), __FILE__ ,
__LINE__ , __FUNCTION__ ); \
sprintf( SysBuf + strlen( SysBuf ), __VA_ARGS__ ); \
xlog( SysBuf ); \
}while(0)


I compile the with Pro*c, but it gave me the error message... ,
however, it's totally correct with gcc.

Only because gcc isn't terribly fussy sometimes. It supports a wide
range of syntaxes (syntaces?) which are not valid C. Turning off such
support can be difficult, but it can certainly be done.

How can solve the problem

Get rid of the non-standard syntax. Pro*C pre-compiles your source code
before passing it on to the compiler, and it's far stricter than gcc
(and rightly so, in my opinion).

 

[jacob navia]

empriser said:

#define XLOG( ... ) \
do{ \
sprintf( SysBuf, "[%s][%s/%d/%s] ", curtime(), __FILE__ ,
__LINE__ , __FUNCTION__ ); \
sprintf( SysBuf + strlen( SysBuf ), __VA_ARGS__ ); \
xlog( SysBuf ); \
}while(0)


I compile the with Pro*c, but it gave me the error message... ,
however, it's totally correct with gcc.

Only because gcc isn't terribly fussy sometimes. It supports a wide
range of syntaxes (syntaces?) which are not valid C. Turning off such
support can be difficult, but it can certainly be done.

How can solve the problem

Get rid of the non-standard syntax. Pro*C pre-compiles your source code
before passing it on to the compiler, and it's far stricter than gcc
(and rightly so, in my opinion).

This is standard syntax.

The current standard is C99, even if you do not like it. Pro*c is not
a compiler that accepts standard C since its development stopped several
years ago.

flames >/dev/null

 

[Richard Heathfield]

jacob navia said:

This is standard syntax.

Not as far as Pro*C is concerned.

The current standard is C99, even if you do not like it.

The current de jure standard is indeed C99, and I have no problem with
that. The current de facto standard is C90, and I have no problem with
that either. When C99 becomes the de facto standard, it will make sense
to answer people's vanilla C questions in C99 terms. Until then, it
remains meaningful to refer to non-C90 syntax as non-standard as far as
the Real World is concerned.

Pro*c is not
a compiler that accepts standard C since its development stopped
several years ago.

Pro*C is not actually a compiler, as that term is commonly used. It is a
precompiler whose principal task is to convert EXEC SQL statements into
C function calls. If it is a compiler at all (and there is indeed some
justification for calling it one if one uses the Aho/Sethi/Ullman
definition of a compiler), it is an embedded-SQL compiler, not a C
compiler; its input is a C-like language in which embedded SQL
statements are legal, and its *output* is C.

 

[Ian Collins]

The current de jure standard is indeed C99, and I have no problem with
that. The current de facto standard is C90, and I have no problem with
that either. When C99 becomes the de facto standard, it will make sense
to answer people's vanilla C questions in C99 terms. Until then, it
remains meaningful to refer to non-C90 syntax as non-standard as far as
the Real World is concerned.

Meaningful maybe, but not helpful. At least qualify what you are saying
as non-standard C90 syntax.

Believe it or not, there are some of us who have compilers that support
most, if not all, C99 syntax.

 

[Richard Heathfield]

Ian Collins said:

Meaningful maybe, but not helpful.

I hear where you're coming from, but I disagree.

At least qualify what you are
saying as non-standard C90 syntax.

Normally, I'd agree, but I would argue that, in this case, the context
(Pro*C) gave sufficient information to make my meaning clear to those
who know what Pro*C is.

Believe it or not, there are some of us who have compilers that
support most, if not all, C99 syntax.

I have a C90-conforming compiler that supports // comments - but only if
I switch off C90 conformance checking. So, to use that C99 feature, I
have to tell my compiler to be less strict, and I consider this a Bad
Thing. Until conforming C99 implementations are the norm, I will
continue to focus more on the de facto C90 standard wherever I consider
it appropriate.

 

[Ian Collins]

I have a C90-conforming compiler that supports // comments - but only if
I switch off C90 conformance checking. So, to use that C99 feature, I
have to tell my compiler to be less strict, and I consider this a Bad
Thing. Until conforming C99 implementations are the norm, I will
continue to focus more on the de facto C90 standard wherever I consider
it appropriate.

Even if a compiler isn't fully C99 conforming, it can still have a
strict C99 mode that enforces the sections of the standard it supports.

 

[Keith Thompson]

jacob navia said: [...]

The current standard is C99, even if you do not like it.

The current de jure standard is indeed C99, and I have no problem with
that. The current de facto standard is C90, and I have no problem with
that either. When C99 becomes the de facto standard, it will make sense
to answer people's vanilla C questions in C99 terms.
Agreed.

Until then, it
remains meaningful to refer to non-C90 syntax as non-standard as far as
the Real World is concerned.

Here I have to disagree. A lot of compilers implement *some* of the
features added in C99, and a lot of programmers find it convenient to
use them, even if the full C99 standard isn't supported. I understand
that you prefer to stick to strict C90, and you have excellent reasons
for doing so, but some programmers are willing to accept the
limitation of being restricted to a particular implementation's
feature set (perhaps in the hope that it will be less of a restriction
as time passes and C99 (hypothetically) catches on).

I think it's not constructive to pretend that C99-specific features
are simply non-standard. During this transitional period (which shows
signs of lasting roughly forever), I think we need to take the extra
time and effort to discuss such features with respect to *both* the
C90 and C99 standards.

jacob seems to think that we should pretend that C90 no longer exists,
and that C99 is the only relevant standard. I strongly disagree with
him, but that doesn't mean ignoring C99 is the answer.

(Incidentally, I had thought that gcc's support for C99-style variadic
macros was incomplete, but the status page has it marked as "DONE"
going all the way back to release 3.0.)

So the answer to the original question is:

The "..." token in a macro parameter list is a new feature in C99 that
didn't exist in C90. gcc supports this feature; Pro*C doesn't.

It may be possible to implement a replacement for the macro in
question:

#define XLOG( ... ) \
do{ \
sprintf( SysBuf, "[%s][%s/%d/%s] ", curtime(), __FILE__ ,
__LINE__ , __FUNCTION__ ); \
sprintf( SysBuf + strlen( SysBuf ), __VA_ARGS__ ); \
xlog( SysBuf ); \
}while(0)

without using a variadic macro, but it's likely to be less convenient.
One solution is to use a variadic function, but you'd probably have to
pass the values of __FILE__, __LINE__, and __FUNCTION__ explicitly.

Oh, and __FUNCTION__ is non-standard; C99 defines __func__, but it's
an implicitly declared identifer, not a macro.

Since Pro*C generates C code as its output, there might also be a
solution that involves post-processing the Pro*C output before feeding
it to gcc, effectively hiding the XLOG macro from Pro*C and then
revealing it to gcc. The Pro*C documentation might offer some ideas.

 

[Keith Thompson]

Ian Collins said:


I hear where you're coming from, but I disagree.


Normally, I'd agree, but I would argue that, in this case, the context
(Pro*C) gave sufficient information to make my meaning clear to those
who know what Pro*C is.

And *only* to those who know what Pro*C is.

Before reading this thread, I either didn't know or had forgotten what
Pro*C is; I certainly had no clue that it happens to support C90 but
not C99. Mentioning that fact in the beginning would have been useful
for those of us who lacked that particular off-topic piece of
information.

[...]

 

[Mark McIntyre]

Ian Collins said:


Normally, I'd agree, but I would argue that, in this case, the context
(Pro*C) gave sufficient information to make my meaning clear to those
who know what Pro*C is.

I disagree, on the same basis that one is expected to retain context.
A post should stand on its own as much as possible.

I have a C90-conforming compiler that supports // comments - but only if
I switch off C90 conformance checking.

I belive Ian was talking about compilers that support C99 usefully.
Its not his fault if you insist on using an antique...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Ian Collins said:

Even if a compiler isn't fully C99 conforming, it can still have a
strict C99 mode that enforces the sections of the standard it
supports.

Yes, that's legal but not compulsory. Not all compilers have such a
feature, by any means.

 

[Ian Collins]

Ian Collins said:


Yes, that's legal but not compulsory. Not all compilers have such a
feature, by any means.

But some do and that's the point. Variadic macros can be used with such
a compiler in conforming mode.

 

[Richard Heathfield]

Ian Collins said:

But some do and that's the point. Variadic macros can be used with
such a compiler in conforming mode.

Undoubtedly, but we're rapidly losing the original context of my remark,
and in any case the discussion is now polarising into the familiar
argument of "code that works on my compiler" versus "code that works
just about everywhere". Whilst the former category is very important, I
don't see it as being particularly interesting in a newsgroup like
comp.lang.c.

For the record, and I'm sorry if it spoils the (incorrect) image that
some people appear to have of me, I'm currently hacking out a Windows
application which wouldn't have a snowball's chance in Arizona of
running under any OS other than Windows. And what's more, I'm writing
it in... in... well, in the *other* language! Non-portable code can be
very interesting - but not *here*, at least not to me.

 

[Ian Collins]

Ian Collins said:


Undoubtedly, but we're rapidly losing the original context of my remark,
and in any case the discussion is now polarising into the familiar
argument of "code that works on my compiler" versus "code that works
just about everywhere". Whilst the former category is very important, I
don't see it as being particularly interesting in a newsgroup like
comp.lang.c.

Your original comment was "Get rid of the non-standard syntax."

My point is that the syntax *is* standard, but not for version of the
standard supported by the tool in question. Hence my request for
clarification.

 

[Stan Milam]

#define XLOG( ... ) \
do{ \
sprintf( SysBuf, "[%s][%s/%d/%s] ", curtime(), __FILE__ ,
__LINE__ , __FUNCTION__ ); \
sprintf( SysBuf + strlen( SysBuf ), __VA_ARGS__ ); \
xlog( SysBuf ); \
}while(0)


I compile the with Pro*c, but it gave me the error message... ,
however, it's totally correct with gcc. How can solve the problem
the proc error message：

Syntax error at line 27, column 15, file ../comm/comm.h:
Error at line 27, column 15 in file ../comm/comm.h
#define XLOG( ... ) \
..............1
PCC-S-02014, Encountered the symbol "..." when expecting one of the
following:

) an identifier, define, elif, else, endif, error, if, ifdef,
ifndef, include, line, pragma, undef, exec, sql, begin, end,
var, type, oracle, an immediate preprocessor command,
a C token, create, function, package, procedure, trigger, or,
replace,
The symbol ")" was substituted for "..." to continue.

Pro*C is a precompiler and as such it must parse through the source code
to identify the SQL. To say it another way the precompiler must be able
to distinguish what is C and what is SQL. You are using the C99 dialect
which Pro*C does not grok and cannot recognize as either C or SQL, so it
thinks it must be an error. If you change XLOG to be a true C function
rather than a macro Pro*C will be happy. It has been my experience that
Pro*C supports C89 and not C99.

Of course, Pro*C is not true C, so it is off-topic, unless we want to
discuss how Pro*C parses C source code.

--
Regards,
Stan Milam
=============================================================
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
=============================================================

 

[Stan Milam]

Ian Collins said:


I hear where you're coming from, but I disagree.


Normally, I'd agree, but I would argue that, in this case, the context
(Pro*C) gave sufficient information to make my meaning clear to those
who know what Pro*C is.


I have a C90-conforming compiler that supports // comments - but only if
I switch off C90 conformance checking. So, to use that C99 feature, I
have to tell my compiler to be less strict, and I consider this a Bad
Thing. Until conforming C99 implementations are the norm, I will
continue to focus more on the de facto C90 standard wherever I consider
it appropriate.

Oh no! Richard and I agree on something. Next thing you know dogs and
cats will be living together.

--
Regards,
Stan Milam
=============================================================
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
=============================================================

 

[Richard Heathfield]

Ian Collins said:

Ian Collins said:

Richard Heathfield wrote:

Ian Collins said:

Richard Heathfield wrote:

I have a C90-conforming compiler that supports // comments - but
only if I switch off C90 conformance checking. So, to use that C99
feature, I have to tell my compiler to be less strict, and I
consider this a Bad Thing. Until conforming C99 implementations
are the norm, I will continue to focus more on the de facto C90
standard wherever I consider it appropriate.

Even if a compiler isn't fully C99 conforming, it can still have a
strict C99 mode that enforces the sections of the standard it
supports.

Yes, that's legal but not compulsory. Not all compilers have such a
feature, by any means.

But some do and that's the point. Variadic macros can be used with
such a compiler in conforming mode.

Undoubtedly, but we're rapidly losing the original context of my
remark, [...]

Your original comment was "Get rid of the non-standard syntax."

And the context within which that comment was made was one of the Pro*C
precompiler, which (as far as I'm aware) does not support, and has
never supported, anything other than C90.

 

[Keith Thompson]

Ian Collins said: [...]

Your original comment was "Get rid of the non-standard syntax."

And the context within which that comment was made was one of the Pro*C
precompiler, which (as far as I'm aware) does not support, and has
never supported, anything other than C90.

And you expected others to know that?