Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #5203 > unrolled thread

Unexpected Difficulty with String Constant Concatenation

Back to article view | Back to comp.lang.c

Contents

  Unexpected Difficulty with String Constant Concatenation Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-06-01 12:45 -0400
    Re: Unexpected Difficulty with String Constant Concatenation Billy Mays <noway@nohow.com> - 2011-06-01 12:49 -0400
      Re: Unexpected Difficulty with String Constant Concatenation Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-06-01 13:19 -0400
    Re: Unexpected Difficulty with String Constant Concatenation blp@cs.stanford.edu (Ben Pfaff) - 2011-06-01 09:50 -0700
    Re: Unexpected Difficulty with String Constant Concatenation Kenneth Brody <kenbrody@spamcop.net> - 2011-06-01 12:56 -0400
      Re: Unexpected Difficulty with String Constant Concatenation blp@cs.stanford.edu (Ben Pfaff) - 2011-06-01 09:59 -0700
        Re: Unexpected Difficulty with String Constant Concatenation Kenneth Brody <kenbrody@spamcop.net> - 2011-06-02 11:07 -0400
          Re: Unexpected Difficulty with String Constant Concatenation Kenneth Brody <kenbrody@spamcop.net> - 2011-06-02 11:22 -0400
          Re: Unexpected Difficulty with String Constant Concatenation Shao Miller <sha0.miller@gmail.com> - 2011-06-02 11:25 -0500
          Re: Unexpected Difficulty with String Constant Concatenation Ben Pfaff <blp@cs.stanford.edu> - 2011-06-02 09:02 -0700
            Re: Unexpected Difficulty with String Constant Concatenation Kenneth Brody <kenbrody@spamcop.net> - 2011-06-03 10:49 -0400
          Re: Unexpected Difficulty with String Constant Concatenation "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-03 01:52 +0100
            Re: Unexpected Difficulty with String Constant Concatenation Keith Thompson <kst-u@mib.org> - 2011-06-02 18:06 -0700
    Re: Unexpected Difficulty with String Constant Concatenation Keith Thompson <kst-u@mib.org> - 2011-06-01 10:07 -0700
    Re: Unexpected Difficulty with String Constant Concatenation Stephen Sprunk <stephen@sprunk.org> - 2011-06-01 13:14 -0500

#5203 — Unexpected Difficulty with String Constant Concatenation

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

[toc] | [next] | [standalone]

#5204

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

[toc] | [prev] | [next] | [standalone]

#5214

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

[toc] | [prev] | [next] | [standalone]

#5205

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.

[toc] | [prev] | [next] | [standalone]

#5208

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

[toc] | [prev] | [next] | [standalone]

#5209

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;}}}

[toc] | [prev] | [next] | [standalone]

#5280

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

[toc] | [prev] | [next] | [standalone]

#5281

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

[toc] | [prev] | [next] | [standalone]

#5282

On 6/2/2011 10: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?
>
> ==========
> 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);
>

Or maybe it's not a bug at all.  5.2.4.1p1 includes "127 parameters in 
one function definition" and "127 arguments in one function call". 
Perhaps one cannot write a 306-parameter function with these compilers. 
  Perhaps, in:

   void func();

It is assumed that 'func' could be a function taking, at most, 305 
arguments, in a call.

[toc] | [prev] | [next] | [standalone]

#5284

Kenneth Brody <kenbrody@spamcop.net> writes:
> ==========
> 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);

But what does it do if you give the function 305 arguments?
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#5361

On 6/2/2011 12:02 PM, Ben Pfaff wrote:
> Kenneth Brody<kenbrody@spamcop.net>  writes:
>> ==========
>> 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);
>
> But what does it do if you give the function 305 arguments?

Same error.  Which is actually what I might expect.  After all, even though 
I gave it 305 arguments, "x" is not a term that evaluates to a function that 
takes 305 arguments.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#5327

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?

A feature surely? It's issuing a diagnostic, which is all that's 
required of it. The diagnostic is even correct, just not particularly 
helpful.

[toc] | [prev] | [next] | [standalone]

#5328

"J. J. Farrell" <jjf@bcs.org.uk> writes:
> 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?
>
> A feature surely? It's issuing a diagnostic, which is all that's 
> required of it. The diagnostic is even correct, just not particularly 
> helpful.

Violations of the language standard are not the only misbehaviors
that can reasonably be called "bugs".  An error messages that
appears when it should, but that misleads the reader about the
reason for the error, indicates a bug.  (In this particular case,
the term really doesn't evaluate to a function taking 305 arguments,
but that's hardly relevant.)

If you disagree, please cite the standard's definition of the word
"bug".  8-)}

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

[toc] | [prev] | [next] | [standalone]

#5211

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.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5219

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web