RE: Extension to the FFI to allow macro expansions to be avoided
On 16 April 2004 11:33, Marcin 'Qrczak' Kowalczyk wrote:
Perhaps we should differentiate by a calling convention between linking to a function directly and generating a source-level C call?
The calling conventions we know would correspond to linking to them directly. They would perform the necessary magic to turn off macros when compiling via C, and they would not need a C compiler when compiling via assembler. There is no need for specifying a C header in this case.
Another calling convention would generate a function wrapper with proper argument types. It would need "foreign type" declarations and included headers. The wrapped calling convention in this case is of course irrelevant, so it's a calling convention rather than a separate flag.
I wondered about that (while writing my last post) but it still seems like a hefty price to pay for the small number of problematic cases we have, and given that you can already write the C stubs by hand to get the desired effect. Hmm, perhaps this falls in to the category of something we expect an external tool to do? Cheers, Simon
W liście z pią, 16-04-2004, godz. 15:25 +0100, Simon Marlow napisał:
I wondered about that (while writing my last post) but it still seems like a hefty price to pay for the small number of problematic cases we have, and given that you can already write the C stubs by hand to get the desired effect. Hmm, perhaps this falls in to the category of something we expect an external tool to do?
I think the preferred way to interface to a C library is via a typechecked C source, not via binary linking. But if it's made harder, programmers are tempted to avoid that. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (2)
-
Marcin 'Qrczak' Kowalczyk -
Simon Marlow