I suspect that comment predates the existence of capi and is trying to avoid having some other actual calling convention like stdcall because the function pointer is actually invoked from some C code in the RTS. capi is a sort of pseudo-calling-convention in that it generates some C code and then calls that stub.
Have you tried using a capi defined funptr there to see what happens?
Thank you, that’s indeed a reasonable suspicion. I haven’t tried because this is for a PR that’s been submitted to me and I actually have no idea how this could blow up in my face later (or even worse, not blow up an silently corrupt stuff)
Why must FinalizerPtr take a foreign function that uses the
ccallcalling convention? Is there a concrete thing preventing GHC from acceptingcapi?I suspect that comment predates the existence of
capiand is trying to avoid having some other actual calling convention likestdcallbecause the function pointer is actually invoked from some C code in the RTS.capiis a sort of pseudo-calling-convention in that it generates some C code and then calls that stub.Have you tried using a capi defined funptr there to see what happens?
Thank you, that’s indeed a reasonable suspicion. I haven’t tried because this is for a PR that’s been submitted to me and I actually have no idea how this could blow up in my face later (or even worse, not blow up an silently corrupt stuff)
I have my answer: cAPI is fine: https://gitlab.haskell.org/ghc/ghc/-/issues/23599