[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Unexpected Difficulty with String Constant Concatenation

Datesfat Chicks

6/1/2011 4:46:00 PM

This code:

#define CONFIG_BEHAVIOR_H_VERSION ("$Header:
/var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
1.1 2011/06/01 16:40:53 dashley Exp $")

const char *C_MAIN_cvcinfo(void)
{
return
(
"$Header:
/var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
1.6 2011/06/01 16:40:14 dashley Exp $"
CONFIG_BEHAVIOR_H_VERSION
);
}

won't compile and gives this error message.

c_main.c(71): error C2064: term does not evaluate to a function taking
305 arguments

However, if I change the preprocessor constant to omit the
parenthesis:

#define CONFIG_BEHAVIOR_H_VERSION "$Header:
/var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
1.1 2011/06/01 16:40:53 dashley Exp $"

it works fine.

Question: what is going on at the parser and compiler level?

I suspect that when I parenthesize the constant it means something
different so that it can't treat it as string concatenation.

Thanks,
DFC
15 Answers

Carl

6/1/2011 4:50:00 PM

0

On 6/1/2011 12:45 PM, Datesfat Chicks wrote:
> This code:
>
> #define CONFIG_BEHAVIOR_H_VERSION ("$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $")
>
> const char *C_MAIN_cvcinfo(void)
> {
> return
> (
> "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
> 1.6 2011/06/01 16:40:14 dashley Exp $"
> CONFIG_BEHAVIOR_H_VERSION
> );
> }
>
> won't compile and gives this error message.
>
> c_main.c(71): error C2064: term does not evaluate to a function taking
> 305 arguments
>
> However, if I change the preprocessor constant to omit the
> parenthesis:
>
> #define CONFIG_BEHAVIOR_H_VERSION "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $"
>
> it works fine.
>
> Question: what is going on at the parser and compiler level?
>
> I suspect that when I parenthesize the constant it means something
> different so that it can't treat it as string concatenation.
>
> Thanks,
> DFC


Shouldn't the newlines be escaped in the #defines with "\"?


#define CONFIG_BEHAVIOR_H_VERSION ("$Header: \
.....

What happens when you only preprocess the file?

--
Bill

blp

6/1/2011 4:51:00 PM

0

Datesfat Chicks <datesfat.chicks@gmail.com> writes:

> [...nasty code...]
> c_main.c(71): error C2064: term does not evaluate to a function taking
> 305 arguments

After preprocessing, your code looks like this:

return ("a"("b"));

That has the syntax of a function call, so the compiler complains
that it is not a valid function call. I don't know why the
compiler thinks that the function should have 305 arguments.

Kenneth Brody

6/1/2011 4:56:00 PM

0

On 6/1/2011 12:45 PM, Datesfat Chicks wrote:
> This code:
>
> #define CONFIG_BEHAVIOR_H_VERSION ("$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $")
>
> const char *C_MAIN_cvcinfo(void)
> {
> return
> (
> "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
> 1.6 2011/06/01 16:40:14 dashley Exp $"
> CONFIG_BEHAVIOR_H_VERSION
> );
> }
>
> won't compile and gives this error message.
>
> c_main.c(71): error C2064: term does not evaluate to a function taking
> 305 arguments
>
> However, if I change the preprocessor constant to omit the
> parenthesis:
>
> #define CONFIG_BEHAVIOR_H_VERSION "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $"
>
> it works fine.
>
> Question: what is going on at the parser and compiler level?
>
> I suspect that when I parenthesize the constant it means something
> different so that it can't treat it as string concatenation.

"Be the compiler."

Let's shorten the string for the sake of space:

=====

#define FIRST_STRING ( "foobar" )

const char *C_MAIN_cvcinfo(void)
{
return
(
"mystring"
FIRST_STRING
);
}

=====

What does the return statement actual look like, once macros are expanded?
(And a little reformatting of the whitespace.)

return( "mystring" ( "foobar" ) );

In other words, it's a function call, with "mystring" (including the quotes)
being the function name/pointer. Obviously, a string literal is not a
function name/pointer.

Remove the parens, and you get:

return( "mystring" "foobar" );

which is perfectly legal, as it concatenates the literals to:

return ("mystringfoobar");

--
Kenneth Brody

blp

6/1/2011 4:59:00 PM

0

Kenneth Brody <kenbrody@spamcop.net> writes:
[massive snippage below]

> On 6/1/2011 12:45 PM, Datesfat Chicks wrote:
>> c_main.c(71): error C2064: term does not evaluate to a function taking
>> 305 arguments

> In other words, it's a function call, with "mystring" (including the
> quotes) being the function name/pointer. Obviously, a string literal
> is not a function name/pointer.

Any idea why the compiler thinks there should be (or, perhaps,
that there are) 305 arguments?
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

Keith Thompson

6/1/2011 5:07:00 PM

0

Datesfat Chicks <datesfat.chicks@gmail.com> writes:
> This code:
>
> #define CONFIG_BEHAVIOR_H_VERSION ("$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $")
>
> const char *C_MAIN_cvcinfo(void)
> {
> return
> (
> "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
> 1.6 2011/06/01 16:40:14 dashley Exp $"
> CONFIG_BEHAVIOR_H_VERSION
> );
> }
>
> won't compile and gives this error message.
>
> c_main.c(71): error C2064: term does not evaluate to a function taking
> 305 arguments

I presume the string literal "$Header: ... Exp $" is actually on one
very long line in your program. In your posted article, it's split
across 3 lines. It would be good to mention this; I briefly assumed
that you were trying to use a multi-line string literal.

(I think your question has been answered.)

> However, if I change the preprocessor constant to omit the
> parenthesis:
>
> #define CONFIG_BEHAVIOR_H_VERSION "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $"
>
> it works fine.
>
> Question: what is going on at the parser and compiler level?
>
> I suspect that when I parenthesize the constant it means something
> different so that it can't treat it as string concatenation.

Concatenation of string literals applies only to literals. A literal in
parentheses is a valid expression, but it's not a literal.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Datesfat Chicks

6/1/2011 5:19:00 PM

0

On Wed, 01 Jun 2011 12:49:43 -0400, Billy Mays <noway@nohow.com>
wrote:
>
>Shouldn't the newlines be escaped in the #defines with "\"?

Sorry, the newlines are an artifact of my newsgroup client. I should
have shortened the lines.

>#define CONFIG_BEHAVIOR_H_VERSION ("$Header: \
>....
>
>What happens when you only preprocess the file?

Unsure.

Thanks, DFC

Datesfat Chicks

6/1/2011 5:21:00 PM

0

On Wed, 01 Jun 2011 09:50:42 -0700, blp@cs.stanford.edu (Ben Pfaff)
wrote:

>Datesfat Chicks <datesfat.chicks@gmail.com> writes:
>
>> [...nasty code...]
>> c_main.c(71): error C2064: term does not evaluate to a function taking
>> 305 arguments
>
>After preprocessing, your code looks like this:
>
> return ("a"("b"));
>
>That has the syntax of a function call, so the compiler complains
>that it is not a valid function call. I don't know why the
>compiler thinks that the function should have 305 arguments.

Yeah, the "305" mystified me as well.

But the rest of my question was answered.

Thanks, DFC

Stephen Sprunk

6/1/2011 6:15:00 PM

0

On 01-Jun-11 11:45, Datesfat Chicks wrote:
> #define CONFIG_BEHAVIOR_H_VERSION ("$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
> 1.1 2011/06/01 16:40:53 dashley Exp $")
>
> const char *C_MAIN_cvcinfo(void)
> {
> return
> (
> "$Header:
> /var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
> 1.6 2011/06/01 16:40:14 dashley Exp $"
> CONFIG_BEHAVIOR_H_VERSION
> );
> }
>
> won't compile and gives this error message.
>
> c_main.c(71): error C2064: term does not evaluate to a function taking
> 305 arguments


% cat c_main.c
#define CONFIG_BEHAVIOR_H_VERSION ("$Header:
/var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/config_behavior.h,v
1.1 2011/06/01 16:40:53 dashley Exp $")

const char *C_MAIN_cvcinfo(void)
{
return
(
"$Header:
/var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
1.6 2011/06/01 16:40:14 dashley Exp $"
CONFIG_BEHAVIOR_H_VERSION
);
}
% gcc c_main.c
c_main.c: In function â??C_MAIN_cvcinfoâ??:
c_main.c:8: error: called object â??"$Header:
/var/lib/cvs/ceq_ceqpctls/ceqpctls/prf_tm_data_collect/prog/prf_tm_data_expand/prf_tm_data_expand/c_main.c,v
1.6 2011/06/01 16:40:14 dashley Exp $"â?? is not a function

That's not so obvious, but it's better than the error you got.

My guess is attempting to call a string literal as a function exposed a
bug in your compiler, causing it to misinterpret some unrelated data
structure as indicating a function with 305 arguments.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Kenneth Brody

6/2/2011 3:08:00 PM

0

On 6/1/2011 12:59 PM, Ben Pfaff wrote:
> Kenneth Brody<kenbrody@spamcop.net> writes:
> [massive snippage below]
>
>> On 6/1/2011 12:45 PM, Datesfat Chicks wrote:
>>> c_main.c(71): error C2064: term does not evaluate to a function taking
>>> 305 arguments
>
>> In other words, it's a function call, with "mystring" (including the
>> quotes) being the function name/pointer. Obviously, a string literal
>> is not a function name/pointer.
>
> Any idea why the compiler thinks there should be (or, perhaps,
> that there are) 305 arguments?

Perhaps it's a bug in the compiler?

==========
C:\temp>type usenet.c
foo()
{
"x"("y");
}

C:\temp>cl /c usenet.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usenet.c
usenet.c(3) : error C2064: term does not evaluate to a function taking 305
arguments

C:\temp>
==========

It gives the same "305 arguments" text regardless of what's in the
"parameter list":

"x"("y","z");
"x"();
"x"(a,b,c);
"x"(1,2,3,4,5);

--
Kenneth Brody

Kenneth Brody

6/2/2011 3:22:00 PM

0

On 6/2/2011 11:07 AM, Kenneth Brody wrote:
> On 6/1/2011 12:59 PM, Ben Pfaff wrote:
>> Kenneth Brody<kenbrody@spamcop.net> writes:
>> [massive snippage below]
>>
>>> On 6/1/2011 12:45 PM, Datesfat Chicks wrote:
>>>> c_main.c(71): error C2064: term does not evaluate to a function taking
>>>> 305 arguments
>>
>>> In other words, it's a function call, with "mystring" (including the
>>> quotes) being the function name/pointer. Obviously, a string literal
>>> is not a function name/pointer.
>>
>> Any idea why the compiler thinks there should be (or, perhaps,
>> that there are) 305 arguments?
>
> Perhaps it's a bug in the compiler?
[... MSVC 2010 output ...]
> usenet.c(3) : error C2064: term does not evaluate to a function taking 305
> arguments
[...]

And, given that MSVC 2005 gives the following error, regardless of the
"parameter list", and the fact that both give the expected error (ie: the
number in the error corresponds to the number of "parameters" actually
given) when compiled as C++, I think it's pretty well confirmed that it's a
compiler bug.

==========
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usenet.c
usenet.c(3) : error C2064: term does not evaluate to a function taking -22
arguments
==========
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usenet.cpp
usenet.cpp(3) : error C2064: term does not evaluate to a function taking 3
arguments
==========

--
Kenneth Brody