- FFI - Haskell.org

Type promotion in ccall arguments
by Simon Marlow 23 Mar '02

23 Mar '02

I can't remember whether this has come up before, but to my surprise I've just discovered that FFI foreign import declarations don't contain enough infomration to be able to determine the correct calling convention for a given C function. Background: recently we "fixed" a bug in GHC's native code generator which was exposed by the following declaration: foreign import ccall unsafe snprintf :: CString -> CSize -> CString -> Float -> IO () the native code generator was passing the Float as a C float on the stack, but snprintf() expects a double. Half-remembering that C specifies that floats should be promoted to doubles in function call arguemts, I modified the NCG to do just this. But the C standard doesn't say this - it says that floats are promoted to doubles only for (a) functions without an ANSI prototype, and (b) vararg functions, for args after the "...". since the NCG can't possibly know whether the function in question has a prototype (this information isn't part of the FFI declaration), it has to pick a calling convention to use. Now, the reasonable thing to do is to pick the "has a prototype" calling convention, because this will be true for most libraries. But in the snprintf case above, the Haskell programmer would still have to explicitly declare the argument type to be a Double. I think something to this effect should be included in the FFI spec. Thoughts? Cheers, Simon

5 4

ADV: Professional Internet Marketing
by Sydney Ferguson 23 Mar '02

23 Mar '02

1 0

[광고] 과일 도매 쇼핑몰 상일71이 문을 열었습니다.
by 상일청과 19 Mar '02

19 Mar '02

Ulead SmartSaver Pro

1 0

RE: Type promotion in ccall arguments
by Simon Peyton-Jones 15 Mar '02

15 Mar '02

| > I'd say it has all the information you need - you were | using it wrong. | | That's fine - but I think the FFI specification should state | somewhere that the signature for a foreign import ccall | should correspond to the type of the C call *after the C | promotion rules have been applied*. Strongly agree. With at least one example for the benefit of dense people likel mw. Simon

1 0

RE: Type promotion in ccall arguments
by Simon Marlow 15 Mar '02

15 Mar '02

> > I can't remember whether this has come up before, but to my surprise > > I've just discovered that FFI foreign import declarations don't > > contain enough infomration to be able to determine the correct > > calling convention for a given C function. > > I'd say it has all the information you need - you were using it wrong. That's fine - but I think the FFI specification should state somewhere that the signature for a foreign import ccall should correspond to the type of the C call *after the C promotion rules have been applied*. > If we don't like having to remember the C promotion rules ourselves, > we could write a tool to do it for us. The ffi is supposed to be a > _mechanism_ to let you call things and on which you can build more > convenient layers. In this case, you can do that so there's no > problem with the ffi. I have no problem with this - indeed, I fully agree that we shouldn't extend the FFI to deal with C's strange promotion rules. Nevertheless, we need to say that we're taking this approach. Similar problems occur with foreign exports: if you declare a foreign export with Float arguments (eg. see addFloat in section 3.4 of the FFI doc), does that correspond to a C function defined like this float addFloat(a,b) float a,b; { return (a+b); } or this float addFloat(float a, float b) { return (a+b); } Clearly the latter form is the desired one, but the FFI addendum should note that, and say that in order to correctly call the function from C you must have a visible prototype. Cheers, Simon

1 0

Hi Papa
by mizkah＠centrin.net.id 08 Mar '02

08 Mar '02

Hi Paps Papa I`ve read this opportunity and I think its great idea to follow this moment. By the way I need some money about 1500 dollars to pay my cost this month. Thanks Paps ohh Please send regards to Mama and tell "dont smoke to much" :) Papa please give me your opinion about this, thanks http://freetrial.sitesell.com/azwaradrian.html

1 0

ADV: Professional Internet Marketing
by Sydney Fergason 06 Mar '02

06 Mar '02

1 0

FFI RC1 - What are you doing to Haskell?
by Anthony Travers 05 Feb '02

05 Feb '02

I'm not sure if ffi(a)haskell.org is the appropriate place for an observation/opinion piece - it was the only mailing list mentioned on the FFI specs release page and in the specs themselves. If there's a more appropriate mailing list for this commentary, let me know. First some background info... Haskell has been my first PL of choice since April 2000 but have been swatting up on the language and related topics since April 1999, so I have a general overview of most of the concepts behind the language and FP in general. "Amateur software research and development" is currently my main recreation (for better or worse!). My primary Haskell system is Hugs, with occasional but slowly increasing usage of HBI & HBC. Enough background... From what I've read, the FFI's approach to achieving interoperability looks like The Death Of One Thousand Cuts for Haskell. This is most clearly demonstrated by those laughable special identifiers (page 3) denoting specific call conventions which future Haskell implementations would have to be contorted into supporting. (what will be next? "chash","asm","intercal", "vb"..?) From http://www.haskell.org/ghc/overview.html: "We think that Haskell is a great language to write applications in, and are dead keen for GHC to be used for this purpose." If we all accept this statement for all mature Haskell compilers the we must hold our ground - rather than dropping down to the standards of other languages, those languages come up to the standard of Haskell. The mechanism to do this already exists in Haskell, but its use has hitherto been confined to Haskell - module imports. The interoperability challenge then becomes: how do I bundle up that C/C++/.NET/Java/etc library into a Haskell module? Encapsulated as Haskell modules, old libraries can then access and be accessed by code from other Haskell modules using the standard import/export mechanism. So instead of having Haskell implementations handle the calling conventions of C, C++, Java, .NET, etc, the Haskell calling convention is handled by the Haskell module encapsulators for C, C++, Java, .NET, etc, hence moving the complexity out of already-complicated Haskell implementations into separate libraries or modules. The problem of Haskell interoperability is reminiscent of the problem regarding numeric types during the original definition of Haskell: how to have overloaded arithmetic operators over separate numeric types (unlike Miranda(TM)) which could be used to define new overloaded functions (unlike Standard ML). In this case the problem becomes: how to enable foreign code access between Haskell and other languages without rewriting the Haskell-side access mechanisms for each language. Type classes were the adopted solution then - perhaps they are the solution now: data C = .... data CPlusPlus = .... data Java = .... data DotNET = .... : : class Foreign l where .... instance Foreign C where .... instance Foreign CPlusPlus where .... instance Foreign Java where .... instance Foreign DotNET where .... : : Anthony Travers (amt DASH public AT dodo DOT com DOT au)

2 1

RE: FFI 1.0 in GHC
by Simon Marlow 04 Feb '02

04 Feb '02

> I have just committed the changes necessary to make GHC > conform to the FFI Addendum 1.0 to the CVS repo. The old > style of foreign declarations is still supported, but causes > deprecation warnings. Fantastic. Thanks! > I had to change one thing in the FFI Report. I renamed the > `IOErrorType' inspection functions from `MarshalError' to > > alreadyExistsErrorType :: IOErrorType > doesNotExistErrorType :: IOErrorType > alreadyInUseErrorType :: IOErrorType > fullErrorType :: IOErrorType > eofErrorType :: IOErrorType > illegalOperationType :: IOErrorType > permissionErrorType :: IOErrorType > userErrorType :: IOErrorType > > The old proposal of using `userError' for the last function > clashed with the function of the same name in the > `Prelude'. Oh yes, I didn't notice that. I think these renamings are fine. > I was wondering whether we should have functions > `isAlreadyExistsErrorType' etc, as otherwise, values of > `IOErrorType' need to be wrapped into an `IOError' before > they can be inspected with the standard routines from `IO'. > But this would just be a convenience, which I am not sure > whether it would really be needed much. So, I haven't added > it. Opinions? I think I mentioned before that I'd like to flesh out the support for building/inspecting IOErrors a bit more. I'd like to see: -- c.f. IO.ioeGetHandle etc. ioeGetType :: IOError -> IOErrorType isAlreadyExistsErrorType :: IOErrorType -> Bool isDoesNotExistErrorType :: IOErrorType -> Bool ... in the New Libraries I plan to export the IOError-manipulating functionality from System.IO.Error. Cheers, Simon

1 0

FFI 1.0 in GHC
by Manuel M. T. Chakravarty 04 Feb '02

04 Feb '02

I have just committed the changes necessary to make GHC conform to the FFI Addendum 1.0 to the CVS repo. The old style of foreign declarations is still supported, but causes deprecation warnings. I had to change one thing in the FFI Report. I renamed the `IOErrorType' inspection functions from `MarshalError' to alreadyExistsErrorType :: IOErrorType doesNotExistErrorType :: IOErrorType alreadyInUseErrorType :: IOErrorType fullErrorType :: IOErrorType eofErrorType :: IOErrorType illegalOperationType :: IOErrorType permissionErrorType :: IOErrorType userErrorType :: IOErrorType The old proposal of using `userError' for the last function clashed with the function of the same name in the `Prelude'. I was wondering whether we should have functions `isAlreadyExistsErrorType' etc, as otherwise, values of `IOErrorType' need to be wrapped into an `IOError' before they can be inspected with the standard routines from `IO'. But this would just be a convenience, which I am not sure whether it would really be needed much. So, I haven't added it. Opinions? Cheers, Manuel

1 0