Thoughts on varargs functions

[uvlad7]

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

[sue445]

@uvlad7 Thank you for Thanks for the nice idea.

but you don't have discussions enabled

Indeed! I enabled discussion in org and convert this issue to discussion.

I will try to respond later regarding the other items in order to summarize my thoughts.

[sue445]

Sorry for the late reply.

I suppose even version that accepts two args, String and C.VALUE would be useful,

I've been thinking about this for a while and this may be the most feasible way.

I don't know if switch is possble

This is possible.

c.f. https://go.dev/tour/methods/16

However, I'm worried that if we do the type conversion from interface to C type for all variable length arguments, that will be the bottleneck

Anyway, it must be possible to achieve with asm, taking architecture and calling conventions into account

This is certainly possible to have multiple source codes for each architecture in Go.
(e.g. foo.go, foo_linux_amd64.go, foo_darwin_arm64.go, foo_windows.go ...)

However, this requires writing source code for all of these, which increases maintenance costs. We need to be able to build them all on CI.

Even if it is theoretically possible to use assemblies, I can't imagine how to implement this. So please throw me a patch.

I will accept all possible patches, but I don't plan to write such code.

[uvlad7]

I took a look again an think it's better to use libffi (libgoffi or sbinet/go-ffi or or achille-roussel/go-ffi or any other wrapper) for that