I’ve written some exploratory code, using a cheap implementation of printf as
the compiled C routine, just to see what is involved. Packing the varargs
arguments into stack space is ugly … perhaps that is what your code does … but
once it's done:
Module.ccall("miniprintf", "null", ["string", "..."], ["%s %f %s %f\n", "foo",
1.234, "goo", 2])
foo 1.23399999999999 goo 2
… although the ellipsis problem rears its ugly head immediately:
Module.ccall("miniprintf", "null", ["string", "..."], ["%s %f %s %d\n", "foo",
1.234, "goo", 2])
foo 1.23399999999999 goo 0
So, yes, we will need to integrate the signature into the varargs identifier. I
think you are suggesting something like this:
Module.ccall("miniprintf", "null", ["string", “[f,s,i]"], ["%s %f %s %d\n",
"foo", 1.234, "goo", 2])
which looks promising.
> On Sep 8, 2017, at 10:19 AM, Jukka Jylänki <juj...@gmail.com> wrote:
>
> The code there is calling a varargs function, but only with a fixed
> number of arguments. The same method applies though for calling an
> arbitrary number of args, one will then use a for loop to populate the
> parameters.
>
> I think we'd want to avoid using an ellipsis string "..." as an
> identifier, but preferably use some other kind of method to identify,
> perhaps just the presence of a secondary array would denote varargs.
> One thing that is important though is that there will need to be a
> field that identifies the signature of the varargs, because it needs
> to be possible to call both integer and float signatures. Non-default
> C conversions can also have integers and floats of different size, so
> we'll need to have a way to be forward compatible to those as well,
> even if we did not implement them right away.
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
