Thoughts on varargs functions #235
Description
First, it's not an actual issue, but you don't have discussions enabled, so here we are.
Second, I'm not an experienced Go or C developer, in fact I only wrote one simple Go program; I can write simple C code, but not some "hacks", that can work safely.
That being said, I believe varargs functions like rb_sprintf are must to have, and that hack used for RbRaise is useless, as these are usually needed for the extensions like PRIsVALUE. I suppose even version that accepts two args, String and C.VALUE would be useful, as is still possible - though less effective - to concatenate multiple strings and to use Go's fmt.Sprintf() for types other than VALUE.
But I suppose it's also possible to create varargs Go function that accepts interface, but in fact only allows a few types (plus VALUE, plus maybe native Go types directly convertible to C types) and auto-generate C functions that simply call varargs. Yeah, event for 1-3 args and 19 types it's gonna be 7239 functions (can be less if poiters aren't needed), and very slow if Go func has to check each arg type through if-s (I don't know if switch is possble), but still worth a shot.
Another, hacky, approach is to try to construct va_list or it's functional analog. It's probably possible to write all Go's varargs into a raw piece of memory, then pass it and its size into a C function, which would create va_list and call v-analog of the Ruby function (rb_vsprintf instead of rb_sprintf). I know, hacking around va_list cannot be a portable solution, it'd depend on ABI (then OS) and architecture (shouldn't depend on the compiler, but anyway Go only supports gcc and clang, if I know right), and even only Linux + MacOs support on x64 and ARM64 would be good enough. As of the hack, I found it's possible to use alloca for that. If va_list is really just a char*, it may work. Anyway, it must be possible to achieve with asm, taking architecture and calling conventions into account. Definitely would worth the effort