I thought, long after the fact, I should clarify the facts underpinning my other comment(s) on this: the reason why this is a problem at all is not actually exactly to do with C functions and arguments.

Perl XS functions get "compiled" into C functions that all take exactly the same C arguments. They get their Perl-level arguments by interacting with the Perl stack, which are described by a number of global C symbols. One of those is items, which says how many Perl arguments are on the Perl stack. Part of the "compiling" generates a bit of C code (look in a .c file generated from a .xs file) that checks that items has an allowed value (there can be several, if there are default values for some arguments). For a ...-ended signature, there will be no maximum, but there will be a minimum of however many non-varargs (without defaults) are given in the XS signature.

That items check is the code that is throwing an error in hv's example XS code. That is why a ... signature would obviate it as a problem in that situation.