Re: [PATCH] sparse: add support for __VA_OPT__

"

On Tue, Feb 24, 2026 at 7:34=E2=80=AFPM Al Viro <[email protected]> w=
rote:
>
> On Tue, Feb 24, 2026 at 06:39:57PM -0800, Chris Li wrote:
>
> > > I guess if you wanted instead of a comma then you could have an empty
> > > __VA_OPT__() or you could pass random things like __VA_OPT__(a b c). =
 I
> > > don't know why you would do that.  In this case, "a" is a macro argum=
ent
> > > so that has to be expanded out.
>
> <sarcasm>
> Then perhaps reading the standard might prove enlightening - possibly
> due to examples that might be in there, or seeing the actual description
> of semantics?  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
> is there and searching for __VA_OPT__ would immediately get you this:
>
> #define SDEF(sname, ...) S sname __VA_OPT__(=3D { __VA_ARGS__ })
> SDEF(foo); // replaced by S foo;
> SDEF(bar, 1, 2); // replaced by S bar =3D { 1, 2 };
>
> Would that answer your question?
> </sarcasm>
>
> > One idea is to add an expand function expand___VA_OPT__, similar to
> > expand_has_feature(). Register it in the dynamic expand macro array.
> > That way you get the collect_arguments() for free and it behaves just
> > like a builtin macro expansion. Just duplicate the collected arg list
> > to the current token, if  there are extra arguments.
>
> Sorry, no go; for one thing, #__VA_OPT__() won't be dealt with that way,

Ah, thanks for the great insight. I did not read the spec and trusted
the gcc behavior instead. I just learn from you that that gcc is buggy
in this regard.
Never mind my bad idea.

> for another there's fun with foo ## __VA_OPT__(arg) (argument is expanded
> *and* subjected to ## - yes, it's possible now).

That is very tricky.  I just took a look at the "6.10.5.1" regarding
__VA_OPT__(). I don't have a good solution yet.

> I have something resembling a workable approach, but there's nasty corner
> case when you mix it with the side effects; that's impossible in standard
> C, but gcc has the sodding __COUNTER__ thing and _that_ makes life really
> interesting.
>
> If there's __VA_OPT__ in the body, we want to expand vararg whether it
> occurs in the body or not.
>
> We want to expand each argument that is present in the body.
>
> Question: should we expand an argument that occurs *only* under __VA_OPT_=
_?
> Note that "expand and discard" is *not* a no-op - expansion of __COUNTER_=
_
> will have visible side effects.  What's more, gcc and clang diverge there=
.
>
> Another kind of side effect is possible in standard C: argument substitut=
ion
> might fail when attempted.  And gcc is arguably broken there - see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D123325 for fun details.
> clang handles that one sanely...
>
> I got stalled waiting for gcc folks to respond, then sidetracked to other
> stuff.  I'll resurrect that stuff later this week.

Lookin forward to your solutions.

Chris