Can we remove EMULATE_FUNCTION_POINTER_CASTS?

[sbc100]

This setting is fairly complex and does not have enough test coverage.

The main user of this setting used to be python but apparently that is no longer the case: #23948 (reply in thread)

[sbc100]

@hoodmane @kripken

[hoodmane]

We haven't used it since 2021 and it was expensive enough that we would really hate to switch back to it. So +1 from me to remove it.

[hoodmane]

Also, all of these things like -sWASM_BIGINT=0 and EMULATE_FUNCTION_POINTER_CASTS that duplicate function pointers create a lot of potential for bugs.

[kripken]

Very cool about not using EMULATE_FUNCTION_POINTER_CASTS in Python any more!

I am not aware of any other users. I suggest we ask on the mailing list, and can remove it based on that.

[bonzini]

Function pointer casts are used heavily by GLib (https://gitlab.gnome.org/GNOME/glib/-/issues/3670), which in turn is used by QEMU. For now QEMU avoids them with only some code uglification, but the deprecation is preventing usage of GObject with Emscripten.

[sbc100]

I'm curious about the statement: "GLib absolutely requires the ability to cast function pointers, and that’s not going to change. Quite apart from g_list_sort() and g_slist_sort(), the whole GObject signal infrastructure depends on it".

To be clear its not casting that is the problem for emscripten but calling function via a signature they were not declared with. Is there some misunderstanding perhaps or does glib actually call the function pointers via the wrong signature (i.e. with more of fewer args than that function takes, or with args that differ from the declaration). I'm pretty sure this is technically undefined behaviour in C isn't it?

<Edit: I commented on the upstream issue so lets continue this conversation there>

[sbc100]

It seems that glib has a hard requirement to be able to call function with too many and too few arguments: https://gitlab.gnome.org/GNOME/glib/-/blob/main/docs/toolchain-requirements.md?ref_type=heads#calling-functions-through-differently-typed-function-pointers

Should we consider un-deprecating this setting in order to support glib applications? I'm inclined to myself.

[kripken]

Yeah, after reading that, I think we should un-deprecate. glib is pretty important. Luckily keeping the feature around is not a major burden.

[hoodmane]

I wonder if glib could benefit from an approach like what Pyodide is using. In particular, what if we had a binaryen pass that took:

call_indirect (i32 i32) -> i32

and replaced it with call call_trampoline_iii which could then use ref.test to check whether the type of the function pointer is () -> i32 (so drop args) or (i32 i32 i32 i32) -> i32 (so add args).

Of course you couldn't handle as many type signatures as EMULATE_FUNCTION_POINTER_CASTS but it would also not be anywhere near as devastatingly slow.

@bonzini See how we handle this for Python here:
https://github.com/python/cpython/blob/main/Python/emscripten_trampoline.c