Hi, current definition of macro __CONCAT() is limited, it does not allow to pass __CONCAT() 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) __CONCAT1(First,__CONCAT1(Second,Third)) __CONCATN(First,__CONCATN(Second,Third)) 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 ? Thanks Petr
Created attachment 934 [details] proposed patch
This macro is traditionally defined this way. Any change can disrupt existing code. There will be no change.