dschuff wrote:

I can see that trying to fix up callsites in Binaryen transparently is probably 
infeasble, although I still have basically the same objections the proposed 
approach that were expressed by @efriedma-quic and myself above. 

I'm doing some prototyping experiments with different approaches, and the way 
I'm validating them is to try locally modifying glib to support Emscripten and 
get the tests to pass (at least, the ones that don't depend on unsupported 
posix features). I hope to have more to say different approaches shortly. But 
the first thing I tried was to apply this patch to clang, and then try to see 
whether it is sufficient to make glib work. 
The first approach was to turn a coding agent loose and let it try to make the 
tests pass. This doesn't result in upstreamable changes, but it does identify 
places in the code that must be modified.

And it appears that this patch is not sufficient to make glib transparently 
work. Mostly because there are plenty of casts in glib that are actually 
runtime casts and not compile-time casts. For example in 
[gslist.c](https://github.com/dschuff/glib/commit/f9fd9acd4213e67eebd71dd74900cfb360ea2ddf#diff-48030e2aa9b604d2a85bf174ef9ea31ef32d5341128d6317544d88a2551f82bbL1032-R1039)
 the list iteration functions are calling callbacks that are either 2-argument 
`GCompareFunc` or 3-argument `GCompareDataFunc`, but it can't tell statically 
which one it is; the cast is a runtime cast. LIkewise 
[g_queue_foreach](https://github.com/dschuff/glib/commit/f9fd9acd4213e67eebd71dd74900cfb360ea2ddf#diff-3196da21408e1f1c02f7923adfdd6680077d395feeeceff925665e711f4c7cb9L84-L87)
 does runtime casts on callbacks of type `GFunc` (2 arguments), but can't tell 
statically when it gets a function that only takes one argument (like 
`free_func` in the example).

It doesn't seem like a flag that has these drawbacks and only implements part 
of a solution is worth it.
 

https://github.com/llvm/llvm-project/pull/153168
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to