April 2004 - FFI - Haskell.org

Extension to the FFI to allow macro expansions to be avoided
by Ian Lynagh 17 Apr '04

17 Apr '04

[This has come from the cvs-ghc list. All the info should be in this mail, though]. The problem =========== Some C libraries (curses is the one I have to hand) provide macros in addition to functions in some cases for efficiency reasons. If you use the FFI to import such a function thus: ----- module Q where import Foreign.Ptr (Ptr) import Foreign.C.Types (CInt) foreign import ccall unsafe "static curses.h wstandend" wstandend :: Ptr a -> IO CInt ----- Then GHC fails if not using the NCG (which AFAIK is available on only handful of platforms; the generated code efficiency may also be an issue if you don't have enough foreign imports to warrant splitting them off into their own module): $ ghc -fffi -c Q.hs -O /tmp/ghc1164.hc: In function `Q_zdwccall_entry': /tmp/ghc1164.hc:29: warning: dereferencing `void *' pointer /tmp/ghc1164.hc:29: error: request for member `_attrs' in something not a structure or union $ as it is creating code like this (line 29 is the one containing "wstandend"): { I_ _ccall_result; StgAddr _ccall_arg1=_B0_; CALLER_SAVE_SYSTEM _ccall_result = (wstandend((_ccall_arg1))); CALLER_RESTORE_SYSTEM _B3_=_ccall_result; } which then gets expanded to this by cpp: { I_ _ccall_result; StgAddr _ccall_arg1=_B0_; _ccall_result = (((((_ccall_arg1))->_attrs = (0L)))); _B3_=_ccall_result; } (there was some disagreement over whether such a macro was poorly written for not casting its argument; either way, the fact remains that this sort of thing is out there, and convincing the rest of the world to change to make things a bit easier for us is not going to happen.). Possible solutions ================== 1 = One solution is to write a C wrapper around each potentially affected function. I don't think this is very satisfactory as it significantly increases the amount of effort needed to create a binding (rather than just a single foreign import statement you now also need a line in a C file and to make sure the object file is built and linked in correctly). 2 = Surrounding the function with parentheses so the macro doesn't match. The offending line above would be _ccall_result = ((wstandend)((_ccall_arg1))); 3 = I haven't tested this, but I assume you could just generate #undef wstandend before the function call. When to fix the problem ======================= (I'm assuming solution 1 is rejected from here on - if it's the one chosen then the rest is irrelevant) The above gives ways to fix the problem, but there were worries that it could cause a significant performance penalty to always do this, including in some of the bits of GHC implementation. Two possible alternatives come to mind. A = Where a cid is permitted also permit '(' cid ')' B = Before the optional '&' in a C impent, allow an optional "nomacro". The implementation would then make sure you didn't get a macro using solution 2, 3 or some other means. ===== Both A and B allow the programmer to highlight where they cannot trust macros to behave as needed (by ghc -fvia-C at least), so the performance hit is taken only when we can't be sure it is safe not to. ===== In case it isn't clear, I don't like solution 1 (which is what we have at the minute), but would be happy with any combination of {1,2} and {A,B}. Thanks Ian

9 15

RE: Extension to the FFI to allow macro expansions to be avoided
by Simon Marlow 17 Apr '04

17 Apr '04

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

2 1

RE: Extension to the FFI to allow macro expansions to be avoided
by Simon Marlow 15 Apr '04

15 Apr '04

> Fergus Henderson wrote: > > [...] the Haskell FFI has sacrificed quality for easy of > implementation. > > If this starts causing problems for users, I think the > right solution > > is to raise the bar for implementations, not to lower it. [...] > > I definitely support Fergus' point of view, GHC and Hugs really rushed > head over heels towards a wrong direction, IMHO. If I see > this correctly, > the only problems were that GHC's native code generator doesn't handle > macros currently and the handling of "broken" macros in the C > back-end and > Hugs. I think we can safely forget about the latter (by using > #undef or > a small wrapper), and we should have a look how to solve the former. > Mercury seems to handle this, although I'm currently not sure at what > price (in terms of implementation effort and possible > performance loss). Fergus, as usual, has a number of good points. I agree that a good FFI should target the C API rather than the ABI, tagetting the ABI is a compromise. The errno example isn't valid here: errno isn't a function, and it isn't guaranteed to be an addressable location either, so the FFI can't access it. There are some other good examples though: on Windows, lots of string functions have two variants, one with an 'A' suffix (ASCII) and one with a 'W' suffix (WIDE), and the plain function name without the suffix is #defined to one or the other based on the value of the UNICODE CPP symbol. The documentation only refers to the un-suffixed version, so in order to write Haskell FFI code that calls these functions you have to dig through the header files, or compile via C, or use a separate C stub. This is really annoying. It's one of those situations where doing The Right Thing hurts you in the pockets, and only fixes a small minority of problematic cases that could be worked around anyway. Worse is better, as they say :-P Cheers, Simon

1 0

RE: Extension to the FFI to allow macro expansions to be avoided
by Simon Marlow 15 Apr '04

15 Apr '04

> On Thu, Apr 08, 2004 at 10:18:24AM +0100, Alastair Reid wrote: > > Now that I understand the problem, my feeling is that the > problem is not with > > curses but with GHC's compilation method. GHC is using a > shortcut by > > pretending that the ffi is for interfacing to cpp+C whereas > the ffi is quite > > clear that it is for interfacing to C. So, I think the > thing to do is fix > > GHC. > > And Hugs too. The issue isn't extending the FFI but implementing it > more accurately and consistently. As you point out, systems compiling > via C have been extending the FFI to a function+macro > interface, which is > incompatible with systems compiling to native code. Having > been bitten by > the same thing in the opposite direction (macros that work > with ffihugs > or ghc -fvia-C don't work with ghc -fasm), I'd favour turning off the > macro interface, preferably with #undef, at least by default. Agreed. Why is #undef to be preferred over adding parentheses around the function name as Ian originally suggested? Contrary to what I first thought, disabling the use of macros in FFI calls should have no impact on GHC, so I'm happy to make this change. Cheers, Simon

3 2

RE: Extension to the FFI to allow macro expansions to be avoided
by Simon Marlow 09 Apr '04

09 Apr '04

> Alastair Reid wrote: > > [...] where the decision to insert parens is decided by a > command-line flag. [...] > > I'm still not convinced that any change is really necessary, > but I'd really > prefer a command-line flag over a change in the FFI syntax. > The latter will > lead to much more portability trouble than the former. Adding a flag is fine by me. Cheers, Simon

1 0