> 1) no ## in the beginning or end of body. [6.10.3.3(1)] > It's a warning, recovery consists in dropping them at #define time. Fixed in the patch I'm testing, and I was wrong about proper recovery - better ignore the entire definition than go on with mangled one. > 2) ## that comes from argument does *not* have a special meaning; > only one from the body does. [6.10.3.3(3)] Fixed. > 3) assuming left-to-right order of evaluation for ## (we are free > to choose any [6.10.3.3(3)] and left-to-right is much easier when we get > to merging tokens), if ## immediately follows another ## it can be treated > as not having a special meaning (it will be merged with whatever precedes > the first one and even if result of merge will be "##", it won't have a > special meaning). IOW, in > a ## b ## ## c ## ## ## d > the 1st, 2nd, 4th and 6th ## will concatenate; 3rd and 5th ones will be > merge arguments and won't merge anything themselves. Fixed. The rest is not - it will be a separate patch. BTW, there's another couple of bugs - see preprocessor9.c and preprocessor10.c for the stuff that triggers them. Parsing of macro bodies should be OK by now; the only missing check is "the only place where __VA_ARGS__ can occur is in the body of macro with argument list ending on ellipsis" and that will be dealt with later. We get three new kinds of tokens - TOKEN_QUOTED_ARGUMENT (unexpanded arguments next to ##), TOKEN_STR_ARGUMENT (#<argument>) and TOKEN_CONCAT (concatenation operator). When we go through the body of macro at #define time, we a) decide which ## will be operators there (see (3) above) and set the type of those to TOKEN_CONCAT; retokenize() is looking for that token_type() now instead of doing match_op(). b) collapse OP[#] IDENT[argument] to a single token - STR_ARGUMENT[argnum]. expand_arguments() looks for that token type instead of messing with match_op() + check that the next one is an argument. c) mark the rest of arguments either as QUOTED_ARGUMENT or MACRO_ARGUMENT, depending on whether they have a concatenation as neighbor or not; expand_arguments() looks for that to decide if expand_one_arg() should do expansion when subsitituting (instead of messing with checking neighbors). All that stuff is done in one pass and comes pretty much for free - see handle_define() for details. And we get a nice payoff at expansion time for that (will get more when we get to collecting the information on arguments uses). preprocessor{8,9,10}.c added; the first one shows the stuff fixed by now; other two are still not handled correctly. I don't see any regression - neither on validation/* stuff nor on full kernel build.