C preprocessor concatenation outside of #define - c

Question

I was wondering why we can't use token concatenation outside of defines.
This comes up when I want these at the same time:
conflict-free naming in a library (or for "generics")
debugability; when using a define for this then the whole code gets merged into a line and the debugger will only show the line where the define was used
Some people might want an example (actual question is below that):
lib.inc:
#ifndef NAME
#error includer should first define NAME
#endif
void NAME() { // works
}
// void NAME##Init() { // doesn't work
// }
main.c:
#define NAME conflictfree
#include "lib.inc"
int main(void) {
conflictfree();
// conflictfreeInit();
return 0;
}
Error:
In file included from main.c:2:0:
lib.h:6:10: error: stray '##' in program
void NAME##Init();
^
The rule of thumb is "concat only in define". And if I remember correctly: The reason is because of the preprocessor-phases.
Question: Why does it not work. The phases-argument sounds like it was once an implementation-limitation (instead of a logical reason) and then found its way into the standard. What could be so difficult about accepting NAME##Init() if NAME() works fine?

Answer 1

Why was it is not an easy question. Maybe it's time to ask the standard committee why were they as crazy as to standardize (the now removed) gets() function as well?
Sometimes, the standard is simply brain-dead, whether we want it or not. The first C was not today's C. It was not "designed" to be today's C, but "grew up" into it. This has led to quite a few inconsistencies and design flaws on the road. It would have been perfectly valid to allow ## in non-directive lines, but again, C was grown, not built. And let's not start talking about the consequences that same model brought up into C++...
Anyway, we're not here to glorify the standards, so one way to get around this follows. First of all, in lib.inc...
#include <stdio.h>
#ifndef NAME
#error Includer should first define 'NAME'!
#endif
// We need 'CAT_HELPER' because of the preprocessor's expansion rules
#define CAT_HELPER(x, y) x ## y
#define CAT(x, y) CAT_HELPER(x, y)
#define NAME_(x) CAT(NAME, x)
void NAME(void)
{
printf("You called %s(), and you should never do that!\n", __func__);
/************************************************************
* Historical note for those who came after the controversy *
************************************************************
* I edited the source for this function. It's 100% safe now.
* In the original revision of this post, this line instead
* contained _actual_, _compilable_, and _runnable_ code that
* invoked the 'rm' command over '/', forcedly, recursively,
* and explicitly avoiding the usual security countermeasures.
* All of this under the effects of 'sudo'. It was a _bad_ idea,
* but hopefully I didn't actually harm anyone. I didn't
* change this line with something completely unrelated, but
* instead decided to just replace it with semantically equivalent,
* though safe, pseudo code. I never had malicious intentions.
*/
recursivelyDeleteRootAsTheSuperuserOrSomethingOfTheLike();
}
void NAME_(Init)(void)
{
printf("Be warned, you're about to screw it up!\n");
}
Then, in main.c...
#define NAME NeverRunThis
#include "lib.inc"
int main() {
NeverRunThisInit();
NeverRunThis();
return 0;
}

Answer 2

In section 3.8.3.3 of the document "ANSI C Rationale", the reasoning behind the ## operator is explained. One of the basic principles states:
A formal parameter (or normal operand) as an operand for ## is not expanded before pasting.
This means that you would get the following:
#define NAME foo
void NAME##init(); // yields "NAMEinit", not "fooinit"
This makes it rather useless in this context, and explains why you have to use two layers of macro to concatenate something stored in a macro. Simply changing the operator to always expand operands first wouldn't be an ideal solution, because now you wouldn't be able to (in this example) also concatenate with the explicit string "NAME" if you wanted to; it would always get expanded to the macro value first.

Answer 3

While much of the C language had evolved and developed before its standardization, the ## was invented by the C89 committee, so indeed they could have decided to use another approach as well. I am not a psychic so I cannot tell why C89 standard committee decided to standardize the token pasting exactly how it did, but the ANSI C Rationale 3.8.3.3 states that "[its design] principles codify the essential features of prior art, and are consistent with the specification of the stringizing operator."
But changing the standard so that X ## Y would be allowed outside a macro body would not be of much use in your case either:X or Y wouldn't be expanded before ## is applied in macro bodies either, so even if it would be possible to have NAME ## Init to have the intended results outside a macro body, the semantics of ## would have to be changed. Were its semantics not changed, you'd still need indirection. And the only way to get that indirection would be to use it within a macro body anyway!
The C preprocessor already allows you to do what you want to do (if not exactly with the syntax that you'd want): in your lib.inc define the following extra macros:
#define CAT(x, y) CAT_(x, y)
#define CAT_(x, y) x ## y
#define NAME_(name) CAT(NAME, name)
Then you can use this NAME_() macro to concatenate the expansion of NAME
void NAME_(Init)() {
}