Increase FuncCastEmulation NUM_PARAMS - #1884

Thanks! Looks good.

Interesting that Ruby needs more parameters here. Do you happen to know where in the code it depends on FuncCastEmulation? (just curious since it's rare - only other case I know of is python)

Before we merge, have you joined the wasm community group?

Sorry, I didn't see the CONTRIBUTING.md. I requested a W3C account but am not yet able to join the group; I'll post again when that changes.

As for why this is happening, I don't quite know what I'm looking at, but I'll tell you what I do know. Calling main() with ASSERTIONS=2 EMULATE_FUNCTION_POINTER_CASTS=0:

Invalid function pointer '1685' called with signature 'iii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an incorrect type, which will fail? (it is worth building your source files with -Werror (warnings are errors), as warnings can indicate undefined behavior which can cause this)
This pointer might make sense in another type signature: ii: 0  iiii: 0  i: _rb_obj_dummy  iiiii: 0  iiiiii: 0  iiiiiii: 0  iiiiiiii: undefined  iiiiiiiii: undefined  iiiiiiiiii: undefined  iiiiiiiiiii: undefined  iiiiiiiiiiii: undefined  iiiiiiiiiiiii: undefined  iiiiiiiiiiiiii: undefined  iiiiiiiiiiiiiii: undefined  iiiiiiiiiiiiiiii: undefined  iiiiiiiiiiiiiiiii: undefined  viii: 0  vii: 0  vi: 0  viiii: 0  jij: 0  viiiii: 0  v: 0  viiiiii: 0  viiiiiiii: undefined  viiiiiiiii: 0  

$1685 is enumerator_init_copy, which is called correctly from C but is additionally exposed to Ruby. Symbolizing the backtrace, the call did indeed come from the Ruby VM machinery:

b8395
_call_cfunc_1
_vm_call0_cfunc_with_frame
_vm_call0_cfunc
_vm_call0_body
_rb_vm_call0
_rb_call0
_rb_call
_rb_funcall
_rb_class_inherited
_rb_define_class
_InitVM_Object
_Init_Object
_rb_call_inits
dynCall_v
…

call_cfunc_1 looks like it should be calling the function pointer with ii, which… would be correct and isn't the signature in the complaint? How do I hunt down b8395?

Hmm, b8395 is probably just the function that throws the error. I think that data is enough - looks like Ruby does the same as Python, and relies on C undefined behavior with function pointer arguments, making this pass necessary.

As this is a small change to a constant, I think we can merge it, but for future contributions it would be important to finish joining the group.

Just stumbled on this PR.

only other case I know of is python

@kripken fyi glib (not glibc) is not great with function pointer casts. Here's a patch I had to apply to avoid function pointer casts back in the asm.js days (emulating function pointer casts increased the output .js size to ~1GB): https://gitlab.com/aidanhs/emwesnoth/-/blob/master/diff-glib.patch

I should try to update that repo for wasm...

Thanks @aidanhs , interesting to know it's not just Python here.