> I just reread that section and can't see anything that contradicts the > idea that the FFI implementation ignores any header files provided. > For example, the phrase: > > "implements calls to C functions ... as if a function prototype for > the called functions is in scope" > > can be interpreted as meaning: > > 1) Will generate code (by generating machine code directly, by > generating C code which is then compiled, or by some other means) > which assumes the existence of a prototype _even if the user does > not supply one_. > > [I see this as the most obvious interpretation of the phrase.] > > 2) Will generate C code which #includes any header files the user has > provided. > > [I see this as a less likely interpretation but it seems to be the > one you intend?]
Neither, I think. You're taking an operational interpretation of that phrase, when it is really just talking about the semantics of the call. For example: a C function which takes a float as an argument has two possible calling conventions: the argument may be promoted to double (used by the C compiler when no prototype is in scope), or it may be passed as a float (used by the C compiler when there is a prototype). The FFI spec simply says that it is the latter calling convention that is used. Whether a header file is supplied or not should not affect the semantics of the call (I'm pretty sure you agree with this, but we seem to have lost track of this central concept somewhere along the way...). Similarly, whether there is a prototype in scope or not should not affect the semantics of the call. The FFI spec doesn't say this explicitly, but I don't think it needs to. > My reading of the whole section is that every mention of users > providing header files and function prototypes refers to compiling the > C code being called not the Haskell code doing the calling. The > examples of using foreign import don't show the use of header files > though the second example needs a header file to compile correctly > with GHC. Only when -fvia-C is on. This is a compiler-specific issue, the FFI doesn't need to say anything about it. > If the intent is that any user-provided header files must be > obeyed, then > I think the spec should explicitly say: > > When a header file containing a function prototype is not provided, > the function calling convention employed is undefined. It may vary > between different operating systems, between different > Haskell compilers, > and between different functions. This is exactly what we *don't* want - the semantics should be specified by the FFI declaration alone, independent of any header files. Again, I'm sure you agree with this - but why do you think that supplying a header file should make a difference to the semantics? > I attach my rewording of the section. Note that I am trying to make > it quite clear that an ffi declaration is not portable unless you > provide function prototypes except in the special case that your C > compiler generates the same code with or without a prototype. I really don't think the FFI spec needs to say anything about this at all. If a particular compiler requires prototypes in order to generate correct code (such as GHC when going via C) then this is a matter for that compiler's documentation. Indeed, the GHC User's Guide does mention this. [ Heh. Now I remember why I didn't like being able to specify header files in the FFI declaration :-) ] > ps I still think we're better off removing header files completely and > having the Haskell type completely determine the calling convention > employed. But since I'm not getting any takers on that, I'll > settle for > pinning down the spec as tightly as possible. Aha! I must have lost track of the discussion because I can't remember at which point someone said that the Haskell type does not completely specify the calling convention. Cheers, Simon _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi