Re: [RFC PATCH] pre-process: add __VA_OPT__ support

Eric Zhang <[email protected]> Wed, 25 Feb 2026 00:14:12 -0800
Newsgroups org.kernel.vger.linux-sparse
Message-ID <[email protected]>
On Wed, Feb 25, 2026 at 06:40:03AM +0000, Al Viro wrote:
> Your variant will break with __VA_OPT__ following #. It won't do the
> right thing with ## either, AFAICS, in case when __VA_OPT__ token list
> is empty.

Thanks for the review Al! Wow|Hummm, supprised now they support case 
like foo ## __VA_OPT__(arg), and I just noticed you've pointed it out
in the previous reply.

Maybe split parse_expansion() into two passes could fix it, smth like
  1. Convert __VA_OPT__(...) → TOKEN_VA_OPT_START...TOKEN_VA_OPT_END
  2. Run the existing #/## handling, with handle_hash() and
     handle_hashhash() taught to recognize the new markers

For # __VA_OPT__(), a stringify flag on TOKEN_VA_OPT_START could
signal substitute() to stringify or produce "" depending on whether
varargs are empty.

For ## adjacent to __VA_OPT__, the existing Concat/Placeholder state
machine in substitute() should handle the empty case naturally once
the ## is properly converted to TOKEN_CONCAT in pass 2.

> Another problem is that having no __VA_ARGS__ in the body should
> *not* be treated as "vararg is empty"

Missed in the test case, but it seems like it can work in the current
version.

> I got stalled waiting for gcc folks to respond, then sidetracked to
> other stuff.  I'll resurrect that stuff later this week.

Then I will look forward to your approach :)

Eric