current definition of macro __CONCAT() is limited, it does not allow to pass
as direct argument of __CONCAT(). The behaviour can be shown by "gcc -E in.c" on
#define __CONCAT1(x,y) x ## y
#define __CONCATN(x,y) __CONCAT1(x,y)
Result of first test is First__CONCAT1(Second,Third), which is correct
behaviour of preprocessor , because "if an argument is stringified or
concatenated, the prescan does not occur".
But intuitively expected behaviour of __CONCAT() would be same as result of
second test - FirstSecondThird.
Please, could you allow chaining of __CONCAT() via atached patch ?
Created attachment 934 [details]
This macro is traditionally defined this way. Any change can disrupt existing
code. There will be no change.