This program fails to compile:
==========
#define A 1
#define B 2
#define MYNUM A.B
float foo(void)
{
return MYNUM;
}
float bar(void)
{
return A.B;
}
==========
It should, in fact, fail to compile -- or more precisely, it must
"draw a diagnostic", after which pretty much anything can happen.
The problem is (and here "tokens" are represented by surrounding
them with angle brackets, <like> <so>) that the required token-stream
after the preprocessing phases of compilation are complete, when
the normal syntax and semantic rules of C take over, begins with:
<float> <foo> <(> <void>
<)> <{> <return> <1>
<.> <2> <;> <}>
In other words, the thing after "return" is not <1.2>-the-number,
but rather the three separate tokens <1>, <.>, and <2>, which
attempts to apply the "." operator to the number 1 and the
(not-)member-name 2.
Equivalently, you might as well have written:
return 1 . 2;
or even:
return 1/**/./**/2;
The latter used to work in the 1980s, in pre-ANSI K&R compilers --
but only in some of them, not all: some actually obeyed what K&R
said about the language in the original White Book.
foo() compiles just fine, returning the float value 1.2, whereas
bar() fails to compile, with:
syntax error : 'constant'
on the "return A.B" line.
This suggests (but does not prove) that the compiler can be shown
to be incorrect by removing function bar(), after which the one
required diagnostic will not occur.
Is this one of those cases where you need an extra layer of macro,
like you do with stringifying things?
If you want to use A.B to make MYNUM to expand to the token <1.2>,
yes -- you would have to apply the token-pasting "##" operator:
#define A 1
#define B 2
#define PASTE_DOT(x, y) x ## . ## y
#define PASTE_EXPAND_DOT(x, y) PASTE_DOT(x, y)
#define MYNUM PASTE_EXPAND_DOT(A, B)
will do the trick.
