## __VA_ARGS__ in binutils-gdb?

[Jan Beulich]

On 20.11.2025 17:18, Nick Alcock via Binutils wrote:
> So I have a use case inside libctf where it looks like variadic macros
> might be useful (souping it up so that all errors emit natural-language
> text into the error/warning stream, in service to reducing the number of
> ECTF_ constants to a sane number now we don't need to rely on them to
> disambiguate which function call failed).
> 
> I'm trying to do this while keeping the number of translatable strings
> down, ideally by keeping the strings the same for the same errors coming
> from different functions, but including the name of the function that
> failed in the output, so I can say (e.g. in ctf_add_decl_tag()):
> 
>   ctf_err_type (fp, type, ECTF_RANGE,
> 	        _("component index %i greater than member count %lu"),
> 	        component_idx, ctf_member_count (fp, type));
> 
> and have it emit this into the err/warning stream:
> 
>   ctf_add_decl_tag (".BTF", 0x402): component index 42 greater than member count 6: argument out of range
> 
> or, for something in which no extra info is needed, we can eschew the
> translatable string entirely and simplify right down, e.g. this from
> ctf_add_member_bitfield():
> 
>   ctf_err_type (fp, type, ECTF_INCOMPLETE, NULL);
> 
> which emits (for a type in a child dict derived from foo/bar.c):
> 
>   ctf_add_member_bitfield ("foo/bar.c", 0x392): type is not a complete type
> 
> (where "type is not a complete type" is what ctf_errmsg() returns for
> ECTF_INCOMPLETE).
> 
> Now obviously the key here is the function name, and I really don't want
> to have to type __func__ in everywhere. So that means a variadic macro.
> But ## __VA_ARGS__ is a GCC-specific compiler extension, and all
> hackarounds for its absence are either horrifying (HAS_COMMA) or too new
> to rely on (__VA_OPT__).

Without you actually showing the intended macro, it's not quite clear to
me whether the extension really needs using. In particular I don't see
why the function name would be the culprit. The need to use ## is generally
tied to __VA_ARGS__ expanding to nothing, where the extra comma would get
in the way. (Which effectively means it's less the macro itself that's of
interest, but the overall set of use sites: Are there any which pass no
extra arguments at all for the variadic part?)

> So I was surprised to find ## __VA_ARGS__ in use in binutils-gdb with no
> configure tests or ifdeffery guarding it; mostly in GDB but also in some
> arch-dependent parts of BFD. So I'm wondering... is ## __VA_ARGS__
> widely enough available that I can use it in libctf? People using
> strange compilers without this GCC extension can always disable libctf,
> but if such compilers are actually still commonplace this would make me
> rather queasy. (I suspect they're rare as anything.)

I'm puzzled here, too: I can find uses of __VA_ARGS__ in bfd/, but none of
## __VA_ARGS__.

I can spot
- one in binutils/objcopy.c,
- one in gas/gen-sframe.h (with exactly one use site),
- two in include/opcode/aarch64.h (guarded by DEBUG_AARCH64),
- two in libsframe/testsuite/sframe-test.h,
- one in opcodes/bfin-dis.c (where the ## could easily be dropped).

The likely reason this has gone through so far is imo a lack of testing in
uncommon environments, possibly together with people not being aware that
they're using an extension. Imo the uses (perhaps with the exception of
debugging-only ones) would better be dropped (and no new ones permitted in).
Oh, and of course I'm not intending to speak for gdb/ and friends here.

Since you mention configure-time testing of the feature: How would you see
a fallback look like if the extension is found unavailable? Without a
pretty generally usable fallback, checking this in configure looks somewhat
pointless to me.

Jan