Possible C preprocessor bug in VBCC...

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

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.

[Karlos]

Incidentally, got this from gcc:

macro.c:12:45: pasting "EXTRACTBRCKTELMNT" and "(" does not give a valid preprocessing token

[Karlos]

Gah, I forgot to say I saw it in both gcc 3.4 and 4.1.

[Karlos]

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"

...

[Karlos]

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.

[Karlos]

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.