>From: [EMAIL PROTECTED]
>On 20 Mar, Joerg Schilling wrote:
>>>From: [EMAIL PROTECTED]
>>> ==> COMPILING "OBJ/i686-linux-cc/cdrecord.o"
>>>cdrecord.c:249:1: directives may not be used inside a macro argument
>>>cdrecord.c:249:1: unterminated argument list invoking macro "printf"
>>>cdrecord.c: In function `main':
>>>cdrecord.c:252: parse error before string constant
>>>cdrecord.c:255: parse error before ')' token
>>
>>>This is compiled with (very) recent gcc (3.1.x). Just duplicated
>>>the code such that the complete macro is contained within
>>>an #if or #else part solves the problem.
>>
>> Unless you are on Next Step which has a buggy C-compiler that does not
>> allow to have your own printf(), printf is definitely a macro!
Sorry this should read printf is definitely _not_ a macro.
>> In addition, I see no reason why such an #if #else
>> constructs should not be allowed in macro parameter lists but
>> it seems to be a gcc limitation with parameterized macros.
>> This on the other side verifies a noncompliance in GCC.
>I ran into the same snag once, but not with GCC. The AIX cc has the
Well the main problem with the original poster was the fact that
the new GCC defines printf to be a parameterized macro.
This is not allowd as it would prevent users to take the address of
the printf function.
>same problem:
>% uname -a
>AIX tf004i 3 4 006009434C00
>% cat test.c
>#define add(a, b) a + b
>add( 1,
>#ifdef ADD_2
> 2
>#else
> 3
>#endif
> )
>% cc -c -E test.c
>#line 9 "test.c"
>1 + #ifdef ADD_2 2 #else 3 #endif
interesting...
>I had been told that it is not guaranteed that the C preprocessor
>evaluates #if #else #endif before macros. The updated edition of the
>Kernigham/Ritchie C book (the one which covers ANSI C) talks about the
>preprocessor in the appendix and puts token evaluation into the same
>phase.
>In the example above the preprocessor could have evaluated the #if
>after the macro, but not with some more complex cases like
> add (
> #ifdef ADD_1_2
> 1, 2
> #else
> 3, 4
> #endif
> )
>which really only work when #ifdef is evaluated before the macro. Is
>there really any rule in a C standard that makes the AIX and GNU C
>behavior noncompliant?
Mmm I would never rely on evaluation order in unclear cases.
With the arglist of printf() as it was the case for the original
poster it is definitely a GCC bug.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
