## __VA_ARGS__ in binutils-gdb?

[Indu]

On 2025-11-20 11:22 p.m., Jan Beulich wrote:
> 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.

The ones in libsframe/sframe-test.h can be removed.  I will send a patch 
soon.