inconsistent macro behavior

inconsistent macro behavior

[Reza Roboubi]

Hi,

this is the test file:

$ cat test.c
#define x "llll
#define y "
char * c =3D x y ;

Now, if I do this:
$ gcc -Wall -E test.c
It works as expected, and produces preprocessed output that is
perfectly compilable.

But, if I do this:
$ gcc -Wall -c test.c -o test.o
Then I get this:
test.c:3: error: missing terminating " character
test.c:3: error: missing terminating " character
test.c:3: error: expected expression before =91;=92 token

The questions are:
a.)  What's even going on here?  Why the apparent inconsistency?
b.)  What _should_ be the correct behavior, both in terms of the
(extended) GNU C language, and also the standard C language?

Thanks so much for your help.

Reza.

Re: inconsistent macro behavior

[David Sveningsson]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

Reza Roboubi skrev:
> Hi,
> 
> this is the test file:
> 
> $ cat test.c
> #define x "llll
> #define y "
> char * c =3D x y ;
> 
> Now, if I do this:
> $ gcc -Wall -E test.c
> It works as expected, and produces preprocessed output that is
> perfectly compilable.
> 
> But, if I do this:
> $ gcc -Wall -c test.c -o test.o
> Then I get this:
> test.c:3: error: missing terminating " character
> test.c:3: error: missing terminating " character
> test.c:3: error: expected expression before =91;=92 token
> 
> The questions are:
> a.)  What's even going on here?  Why the apparent inconsistency?
> b.)  What _should_ be the correct behavior, both in terms of the
> (extended) GNU C language, and also the standard C language?
> 
> Thanks so much for your help.
> 
> Reza.
> 

I believe that each c-style string must be encapsulated with " even for 
the preprocessor to work. Actually, at least gcc-4.3 emits warnings 
about missing termination for both line 1 and 2 in your test case.

Perhaps you could work something out with the ## concatenation operator?
-- 


//*David Sveningsson [eXt]*

Freelance coder | Game Development Student
http://sidvind.com

Thou shalt make thy program's purpose and structure clear to thy fellow 
man by using the One True Brace Style, even if thou likest it not, for 
thy creativity is better used in solving problems than in creating 
beautiful new impediments to understanding.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: inconsistent macro behavior

[Reza Roboubi]

Reza Roboubi wrote:
> Hi,
> 
> this is the test file:
> 
> $ cat test.c
> #define x "llll
> #define y "
> char * c =3D x y ;

I apologize.  Obviously '3D' on the last line is a typo.  It should be
char * c = x y;

Reza.

Re: inconsistent macro behavior

[Reza Roboubi]

David Sveningsson wrote:
>> The questions are:
>> a.)  What's even going on here?  Why the apparent inconsistency?
>> b.)  What _should_ be the correct behavior, both in terms of the
>> (extended) GNU C language, and also the standard C language?

> 
> I believe that each c-style string must be encapsulated with " even for 
> the preprocessor to work. Actually, at least gcc-4.3 emits warnings 
> about missing termination for both line 1 and 2 in your test case.
> 
> Perhaps you could work something out with the ## concatenation operator?

Thanks for your replies.

So, double quotes are needed, but I'm still wondering why these behave 
differently:
$ gcc -Wall -E test.c
$ gcc -Wall -c test.c

I mean, what does the gcc back end do _differently_ for those two commands?
---------------------------------------
As a side note, I just checked Torvalds' sparse compiler, and 
interestingly, it returns:

test.c:2:1: warning: Newline in string or character constant
char * c = "llll\n#define y " y ;

In other words, it is amalgamating lines 1+2 into a single string 
literal.  However, sparse does this consistently, regardless of of 
whether I use sparse -E or sparse -c.  So, I can understand what it's doing.

Reza.

RE: inconsistent macro behavior

[Jay]

  --Forwarded Message Attachment--
 >  Date: Sun, 27 Jul 2008 20:24:57 -0700
 >  ext@sidvind.com
 >  [R] reza@parvan.net
 >  To: gcc-help@gcc.gnu.org
 >  Subject: inconsistent macro behavior


[R] ... 
[R] #define x "llll 
[R] #define y " 
[R] ... 
 
 
Search the web for "preprocessor tokenization". 
 
The preprocessor is a bit strange. It resembles:
  - spec the existing (at the time) implementation(s)
  - spec something that is "reasonable" for "reasonable" "interesting' input
  - for input that is NOT "reasonable" and/or "interesting", favor existing implementation(s), even IF it doesn't make much sense
  - for input that IS "reasonable" and/or "interesting", walk a tightrope between existing implementation(s) and making sense, not always possible to do both, but often


As well, the C/C++ preprocessor is often used against other than C/C++ code, but it wasn't really designed for such, and doesn't always work well.


Microsoft Visual C++ does not like it either: 


D:\Documents and Settings\jay>type 5.c
 #define x "llll
 #define y "


D:\Documents and Settings\jay>cl -c  5.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
5.c
5.c(1) : error C2001: newline in constant
5.c(2) : error C2001: newline in constant

D:\Documents and Settings\jay>cl -c -E  5.c
5.c
#line 1 "5.c"
 5.c(1) : error C2001: newline in constant
 5.c(2) : error C2001: newline in constant


 - Jay