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