Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Jose on March 28, 2007, 10:39:25 PM
-
I've stripped down (with many sweat, blood and almost tears, macro debugging is not for the fainthearted I tell you:() an error I was having in a big complicated macro I'm doing to the code bellow. It runs perfectly in SASC(68k) but not on VBCC, wich complains about an invalid created token. Don't have GCC installed to try but it worked on a PC with Borland compiler;).
So, can someone confirm if this is a bug in VBCC, a nonstandard feature that SASC and Borland's preprocessors happend to have, or what ? Asking this as I want the macro to run on any C compliant compiler (whatever that means:)).
Oh, and since we're at it maybe someone could also try it on GCC, I don't fell like installing it.
Cheers fellow coders :pint:
#include<stdio.h>
#define EXTRACTBRCKTELMNT(Terminator, Elmnt) #Elmnt, #Terminator
#define GETBRCKTELMNT(ToExtract) GETELMNTEXPAND(EXTRACTBRCKTELMNT##ToExtract)
#define GETELMNTEXPAND(a) GETELMNTEXPAND2 (a)
#define GETELMNTEXPAND2(a, b) a, b
int main (int argc, char **argv)
{ printf("%s %s\n", GETBRCKTELMNT((YYY, XXX)));
getchar();
return (0);
}
-
I think you can get VBCC to show you the emitted C code after the preprocessing stage (just as you can get it to show you the asm before and after going through the instruction scheduler)
I'll give it a try in a few different compilers tomorrow if I get a minute at work ;-)
Asking this as I want the macro to run on any C compliant compiler
This is a bit of a misnomer really. Macro syntax really isn't anything whatsoever to do with the C language - no more than your favourite macro assembler is anything to do with 68K assembly language ;-)
That said, preprocessor behaviour tends to be well defined in the majority of cases, but I have always been of the opinion that overuse of function-like macros in C is a bad idea.
-
Incidentally, got this from gcc:
macro.c:12:45: pasting "EXTRACTBRCKTELMNT" and "(" does not give a valid preprocessing token
-
Karlos wrote:
Incidentally, got this from gcc:
macro.c:12:45: pasting "EXTRACTBRCKTELMNT" and "(" does not give a valid preprocessing token
gcc 4.1 on x86 Linux gives
test.c:11:1: error: pasting "EXTRACTBRCKTELMNT" and "(" does not give a valid preprocessing token
gcc 2.95.3 on MorphOS gives no errors or warnings at all.
when the resulting executable is run it returns "XXX YYY".
-
Gah, I forgot to say I saw it in both gcc 3.4 and 4.1.
-
@Karlos
" I think you can get VBCC to show you the emitted C code after the preprocessing stage (just as you can get it to show you the asm before and after going through the instruction scheduler)"
The -E option, doesn't allways work as expected...
"I'll give it a try in a few different compilers tomorrow if I get a minute at work "
Cool:)
"That said, preprocessor behaviour tends to be well defined in the majority of cases.. "
I know that at least C99 finally "standardized" varargs macros so there must be some standard.
@CannonFodder
Yes, that's the expected result (on 2.95.3/MOS that is)
So can this be considered a preprocessor bug because obviously I'm not pasting "EXTRACTBRCKTELMNT" and "(", but "EXTRACTBRCKTELMNT" and "(YYY, XXX)" wich IS a valid token :getmad:
-
Difficult to say if it is a bug or not. It looks like it is, but without a solid preprocessor specification to compare against, I can't say with certainty.
Given this:
#define EXTRACTBRCKTELMNT(Terminator, Elmnt) #Elmnt, #Terminator
#define GETBRCKTELMNT(ToExtract) GETELMNTEXPAND(EXTRACTBRCKTELMNT##ToExtract)
#define GETELMNTEXPAND(a) GETELMNTEXPAND2 (a)
#define GETELMNTEXPAND2(a, b) a, b
let's see a manual expansion:
GETBRCKTELMNT((YYY, XXX))
becomes (expanding GETBRCKTELMNT)
GETELMNTEXPAND(EXTRACTBRCKTELMNT##(YYY, XXX))
becomes (and this is presumably the step it doesnt like)
GETELMNTEXPAND(EXTRACTBRCKTELMNT(YYY, XXX))
becomes (expanding EXTRACTBRCKTELMNT)
GETELMNTEXPAND("YYY", "XXX")
becomes
GETELMNTEXPAND2("YYY", "XXX")
becomes
"YYY", "XXX"
...
-
The C Preprocessor for GCC (Richard Stallman) (http://www.la.utexas.edu/lab/software/devtool/gnu/cpp/cpp.html#SEC_Top)
I've read this a while ago (the parts about Macros and Pitfalls and Subtleties of Macros) and can't see why it shouldn't work.
Have you tried with different compilers at work ? Should be interesting...8-)
:pint:
-
I couldn't get it to work on any x86 gcc from 3.0 up, it spat out the same error.
That in itself is not necessarily that surprising. Most of the changes over successive versions occur to the compiler itself rather than the preprocessor component.
-
Right, thx for testing it. I'm gonna check where in the GCC dev forums I should submit this...
-
One thing I thought of trying was simply preprocessing the source using cpp from 2.95.3 and then compiling the output in a higher compiler version.
That's not exactly a practical thing to write a decent makefile for, though.