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.

[Ian Collins]

Re: Problem with Pro*c

empriser wrote:

#define XLOG( ... ) \

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

--
Ian Collins.

[Erik de Castro Lopo]

Re: Problem with Pro*c

empriser wrote:

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.

[Richard Heathfield]

Re: Problem with Pro*c

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).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[jacob navia]

Re: Problem with Pro*c

Richard Heathfield wrote:

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]

Re: Problem with Pro*c

jacob navia said:

Richard Heathfield wrote:

>empriser said:
>>

<snip>

>>

>>>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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: Problem with Pro*c

Richard Heathfield wrote:

>
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.

--
Ian Collins.

[Richard Heathfield]

Re: Problem with Pro*c

Ian Collins said:

Richard Heathfield wrote:

>>
>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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: Problem with Pro*c

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.

--
Ian Collins.

[Keith Thompson]

Re: Problem with Pro*c

Richard Heathfield <rjh@see.sig.in validwrites:

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 (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: Problem with Pro*c

Richard Heathfield <rjh@see.sig.in validwrites:

Ian Collins said:
>

>Richard Heathfield wrote:

>>>
>>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.

>
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.

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.

[...]

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Mark McIntyre]

Re: Problem with Pro*c

On Thu, 01 Mar 2007 21:43:48 +0000, in comp.lang.c , Richard
Heathfield <rjh@see.sig.in validwrote:

>Ian Collins said:
>

>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.

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

>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.

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]

Re: Problem with Pro*c

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: Problem with Pro*c

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.

--
Ian Collins.

[Richard Heathfield]

Re: Problem with Pro*c

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,
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.