469,330 Members | 1,399 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,330 developers. It's quick & easy.

Problem with Pro*c

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

Mar 1 '07 #1
26 7769
empriser wrote:
#define XLOG( ... ) \
Is this compiler a C99 compiler? variadic macros were introduced in C99.

--
Ian Collins.
Mar 1 '07 #2
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.
Mar 1 '07 #3
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.
Mar 1 '07 #4
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
Mar 1 '07 #5
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.
Mar 1 '07 #6
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.
Mar 1 '07 #7
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.
Mar 1 '07 #8
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.
Mar 1 '07 #9
Richard Heathfield <rj*@see.sig.invalidwrites:
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_Keith) ks***@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"
Mar 1 '07 #10
Richard Heathfield <rj*@see.sig.invalidwrites:
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_Keith) ks***@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"
Mar 1 '07 #11
On Thu, 01 Mar 2007 21:43:48 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
>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
Mar 1 '07 #12
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.
Mar 2 '07 #13
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.
Mar 2 '07 #14
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.
Mar 2 '07 #15
Richard Heathfield wrote:
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.
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.

--
Ian Collins.
Mar 2 '07 #16
empriser wrote:
#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.
================================================== ===========
Mar 2 '07 #17
Richard Heathfield wrote:
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.
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.
================================================== ===========
Mar 2 '07 #18
Ian Collins said:
Richard Heathfield wrote:
>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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 2 '07 #19
Richard Heathfield <rj*@see.sig.invalidwrites:
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?

--
Keith Thompson (The_Other_Keith) ks***@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"
Mar 2 '07 #20
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>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?
I expected the OP to know that.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 2 '07 #21
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>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?

I expected the OP to know that.
I see no indication that the OP knew that, or that he knew that
variadic macros are a C99 feature. And you weren't just talking to
the OP.

--
Keith Thompson (The_Other_Keith) ks***@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"
Mar 2 '07 #22
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Keith Thompson said:
>>Richard Heathfield <rj*@see.sig.invalidwrites:
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?

I expected the OP to know that.

I see no indication that the OP knew that, or that he knew that
variadic macros are a C99 feature.
I misspoke. (Never reply in a hurry, Richard.) I mean that I expected
the OP to realise what I meant, and I suspect that he did indeed
realise that. Of course, I could be wrong about that.
And you weren't just talking to the OP.
Nevertheless, I was more interested in giving him a useful answer than
in providing Yet Another Public Lecture.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 2 '07 #23
Richard Heathfield wrote:
>
.... snip ...
>
Nevertheless, I was more interested in giving him a useful answer
than in providing Yet Another Public Lecture.
Popularly known as YAPping.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

Mar 2 '07 #24
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
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?

I expected the OP to know that.

I see no indication that the OP knew that, or that he knew that
variadic macros are a C99 feature.

I misspoke. (Never reply in a hurry, Richard.) I mean that I expected
the OP to realise what I meant, and I suspect that he did indeed
realise that. Of course, I could be wrong about that.
>And you weren't just talking to the OP.

Nevertheless, I was more interested in giving him a useful answer than
in providing Yet Another Public Lecture.
And how did that work out? 8-)}

--
Keith Thompson (The_Other_Keith) ks***@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"
Mar 2 '07 #25
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Keith Thompson said:
<snip>
>>And you weren't just talking to the OP.

Nevertheless, I was more interested in giving him a useful answer
than in providing Yet Another Public Lecture.

And how did that work out? 8-)}
Pretty well. I gained a new fan (Stan Milam). He is now a fully paid-up
member of the "If it were good enough for us fifteen year since, it're
still good enough today" Club. (Stan - your badge and cipher wheel will
be in the post as soon as your cheque clears.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 2 '07 #26
Richard Heathfield wrote:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Keith Thompson said:

<snip>
>>>And you weren't just talking to the OP.
Nevertheless, I was more interested in giving him a useful answer
than in providing Yet Another Public Lecture.
And how did that work out? 8-)}

Pretty well. I gained a new fan (Stan Milam). He is now a fully paid-up
member of the "If it were good enough for us fifteen year since, it're
still good enough today" Club. (Stan - your badge and cipher wheel will
be in the post as soon as your cheque clears.)
Hum, I do not know if this is a good thing.... Can't wait to play with
the cipher wheel :-).

--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========
Mar 4 '07 #27

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Nina Harris | last post: by
2 posts views Thread by Peter Parker | last post: by
3 posts views Thread by Marco Jez | last post: by
1 post views Thread by Mahesh Devjibhai Dhola | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Purva khokhar | last post: by
reply views Thread by haryvincent176 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.