Ah I don't believe it does but they are normally bundled under the "complicated macros that add features or significantly change how C code is written" category which is what I thought you were referring to.
Using xacros to generate a lot of boring data or simplistic init code is definitely worth the potential confusion/complexity for the reader, and they will no doubt appreciate the reduced effort in maintaining it despite potentially having to come out of their C comfort zone a bit. I've used macros to add or change control structures myself. I will sometimes use a TRY macro that runs an expression and returns when its value indicates an error (which reduces line count significantly in some files), but there are almost no caveats with that one and you can look at the macro definition and understand it immediately. Most of us use ARRAY_LENGTH or DIM macro to get the length of a fully typed array, this is highly conventional so there's no confusion.
But this article is adding tweaks to C control flow that really I could live without and are just about complicated enough to scare and waste the time of anyone stuck maintaining it, that's my concern. It's a real concern, based on my own experience and watching the many C programmers around me tackle fixing or upgrading such code. Macros that try to be "too smart" and try to simplify or make some control structure in C more elegant with hidden complexity and caveats under its preprocessor hood are harder to maintain, I don't think the 'nicer' code you get is worth the extra work maintaining it. It's probably applied with the least potential cost in a code base that will be written and maintained by only one person, but most professional C you need to assume will be maintained by other people as well as yourself. That's the angle I'm coming from.
