nativecall and variable argument lists

[Marcel Timmerman]

Hi,

Is there a way to declare a native sub in such a way that it can handle 
variable argument lists? For example sprintf()?

While I'm at it, another question; I need to define native subs which 
can receive a function as an argument to be used as a callback. Why do I 
have to specify the signature of that function? It is quite strict so I 
have to define more than one sub with different callback signatures. An 
example from GTK signals.

gulong
g_signal_connect_object (/|gpointer instance|/,
                         /|const gchar *detailed_signal|/,
                         /|GCallback 
<https://developer.gnome.org/gobject/stable/gobject-Closures.html#GCallback> 
c_handler|/,
                         /|gpointer gobject|/,
                         /|GConnectFlags 
<https://developer.gnome.org/gobject/stable/gobject-Signals.html#GConnectFlags> 
connect_flags|/);


I have to define it like so

my Signature $signal-type = :( N-GObject, OpaquePointer );
my Signature $event-type = :( N-GObject, OpaquePointer, OpaquePointer );

sub g_signal_connect_object(
  N-GObject $widget, Str $signal, Callable $handler
  --> uint64
) {
  my @args = $widget, $signal, $handler, OpaquePointer, 0;
  given $handler.signature {
    when $signal-type { _g_signal_connect_object_signal(|@args) }
    when $event-type { _g_signal_connect_object_event(|@args) }
    default {
      die X::Gnome.new(:message('Handler doesn\'t have proper signature'));
    }
  }
}

sub _g_signal_connect_object_signal(
  N-GObject $widget, Str $signal,
  Callable $handler ( N-GObject, OpaquePointer ),
  OpaquePointer $data, int32 $connect_flags
) returns uint64
  is native(&gobject-lib)
  is symbol('g_signal_connect_object')
  { * }

sub _g_signal_connect_object_event(
  N-GObject $widget, Str $signal,
  Callable $handler ( N-GObject, OpaquePointer, OpaquePointer ),
  OpaquePointer $data, int32 $connect_flags
) returns uint64
  is native(&gobject-lib)
  is symbol('g_signal_connect_object')
  { * }


There are many more handler signatures so it makes it cumbersome to make 
a new definition just because of a different handler signature.


Regards
Marcel