String concatenation

[Pan]

#include <stdio.h>
#define MYSTR "World"

void foo(char *p)
{
puts(p);
}

int main()
{
foo("Hello" MYSTR);
}

Is this guaranteed to print HelloWorld - it does so on my system,
but just wanted to check.
Basically I wanted to know how to pass a concat of 2 strings, one
of which is in a macro into a function.

 

[Pan]

Pan said:


Yes (and a newline).


Two string literals, yes. Whether one or the other or neither or both is
a macro is neither here nor there, but they must both be string
literals if you want the preprocessor to glue them together for you.

Thank you, Richard.
I assume this would work for more than 2 also
i.e.

foo("Hello" MYSTR "Goodbye");

 

[Richard Heathfield]

Pan said:

#include <stdio.h>
#define MYSTR "World"

void foo(char *p)
{
puts(p);
}

int main()
{
foo("Hello" MYSTR);
}

Is this guaranteed to print HelloWorld - it does so on my system,
but just wanted to check.

Yes (and a newline).

Basically I wanted to know how to pass a concat of 2 strings, one
of which is in a macro into a function.

Two string literals, yes. Whether one or the other or neither or both is
a macro is neither here nor there, but they must both be string
literals if you want the preprocessor to glue them together for you.

 

[Richard Heathfield]

Pan said:

I assume this would work for more than 2 also
i.e.

foo("Hello" MYSTR "Goodbye");

puts("Yes, that's"
" right, you"
" can glue t"
"ogether as "
"many as you"
" like (with"
"in reason).");

 

[CBFalconer]

Pan said:



puts("Yes, that's"
" right, you"
" can glue t"
"ogether as "
"many as you"
" like (with"
"in reason).");

Where "in reason" translates to about 500 chars. It is specified
in the standard somewhere.

 

[Richard Tobin]

Where "in reason" translates to about 500 chars. It is specified
in the standard somewhere.

Just before the limit of 32767 bytes in an object.

-- Richard

 

[Charlie Gordon]

Pan said:


Yes (and a newline).


Two string literals, yes. Whether one or the other or neither or both is
a macro is neither here nor there, but they must both be string
literals if you want the preprocessor to glue them together for you.

This is a late reply, but contrary to popular belief, it is not the
preprocessor that glues adjacent string literals together, but the compiler
in translation phase 6 (6.4.5p4).

 

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...


This is a late reply, but contrary to popular belief, it is not the
preprocessor that glues adjacent string literals together, but the
compiler in translation phase 6 (6.4.5p4).

It's the implementation, in fact: and phase 6 comes *before* translation
(which happens in TP7), so it's still *pre*-processing. I have read
6.4.5(4) and failed to find any mention of a compiler.

 

[Charlie Gordon]

Charlie Gordon said:


It's the implementation, in fact: and phase 6 comes *before* translation
(which happens in TP7), so it's still *pre*-processing. I have read
6.4.5(4) and failed to find any mention of a compiler.

All C preprocessors I have tested leave the adjacent strings intact. It
does not prove my point beyond common sense understanding of the split
between "preprocessing" and "compiling".

Translation phases are described in c99 5.1.1.2: it is clear that
translation phase 4 is included in the "preprocessing". Translation phase 5
would have to be reverted for "preprocessing output" to be produced. I
think it implies that "preprocessing" covers phases 1 through 4, but
excludes phases 5 and 6, but it would not break much to include them and go
through extra work to produce parsable output where adjacent string literals
have been concatenated. It is just not what compiler writers seem to
choose.