«

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

"Richard Heathfield" <> wrote in message
news:...
> 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.

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

foo("Hello" MYSTR "Goodbye");

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 <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Pan said:

<snip>

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Pan said:
>
> <snip>
>
>> 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).");

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

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



--
Posted via a free Usenet account from http://www.teranews.com

In article <>,
CBFalconer <> wrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

"Richard Heathfield" <> a écrit dans le message de news:
...
> 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.

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

--
Chqrlie.

Charlie Gordon said:

> "Richard Heathfield" <> a écrit dans le message de
> news: ...

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

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Richard Heathfield" <> a écrit dans le message de news:
...
> Charlie Gordon said:
>
>> "Richard Heathfield" <> a écrit dans le message de
>> news: ...
>
> <snip>
>>>
>>> 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).
>
> 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.

--
Chqrlie.