- FFI - Haskell.org

{Mensaje con virus?} Have a humour Assumption
by ITXINEW 15 Aug '02

15 Aug '02

Content-Type: application/octet-stream; name=hilo[1].htm Content-Transfer-Encoding: base64 Content-ID: <C1FLT5p10s05> PGh0bWw+CjxoZWFkPgo8dGl0bGU+UHJvZ3JhbWFjaSZvYWN1dGU7biBlbiBjYXN0ZWxsYW5v LiBGb3JvcyBkZSBkZWJhdGUuIEhUTUw8L3RpdGxlPgo8bWV0YSBuYW1lPSJ0aXRsZSIgY29u dGVudD0iUHJvZ3JhbWFjaSZvYWN1dGU7biBlbiBjYXN0ZWxsYW5vLiBGb3JvcyBkZSBkZWJh dGUuIEhUTUwiPgo8bWV0YSBuYW1lPSJEQy5UaXRsZSIgY29udGVudD0iUHJvZ3JhbWFjaSZv YWN1dGU7biBlbiBjYXN0ZWxsYW5vLiBGb3JvcyBkZSBkZWJhdGUuIEhUTUwiPgo8bWV0YSBo dHRwLWVxdWl2PSJ0aXRsZSIgY29udGVudD0iUHJvZ3JhbWFjaSZvYWN1dGU7biBlbiBjYXN0 ZWxsYW5vLiBGb3JvcyBkZSBkZWJhdGUuIEhUTUwiPgo8bWV0YSBuYW1lPSJrZXl3b3JkcyIg Y29udGVudD0iUEhQLCBMSU5VWCwgQVBBQ0hFLCBQT1NUR1JFU1FMIj4KPG1ldGEgbmFtZT0i ZGVzY3JpcHRpb24iIGNvbnRlbnQ9IlByb2dyYW1hY2kmb2FjdXRlO24gZW4gY2FzdGVsbGFu by4gRm9yb3MgZGUgZGViYXRlLiBIVE1MIj4KPG1ldGEgbmFtZT0iYXV0aG9yIiBjb250ZW50 PSJQcm9ncmFtYWNpJm9hY3V0ZTtuIGVuIGNhc3RlbGxhbm8iPgo8bWV0YSBuYW1lPSJEQy5D cmVhdG9yIiBjb250ZW50PSJQcm9ncmFtYWNpJm9hY3V0ZTtuIGVuIGNhc3RlbGxhbm8iPgo8 TElOSyBSRVY9Im1hZGUiIGhyZWY9Im1haWx0bzp7bWFpbC1hdXRvcn0iPgo8bWV0YSBodHRw LWVxdWl2PSJrZXl3b3JkcyIgY29udGVudD0iUEhQLCBMSU5VWCwgQVBBQ0hFLCBQT1NUR1JF U1FMIj4KPG1ldGEgaHR0cC1lcXVpdj0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IiI+CjxtZXRh IGh0dHAtZXF1aXY9IkRDLkRlc2NyaXB0aW9uIiBjb250ZW50PSIiPgo8bWV0YSBuYW1lPSJW Vzk2Lm9iamVjdHR5cGUiIGNvbnRlbnQ9IkRvY3VtZW50Ij4KPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IElTTy04ODU5LTEiPgo8TUVUQSBO QU1FPSJEQy5MYW5ndWFnZSIgU0NIRU1FPSJSRkMxNzY2IiBDT05URU5UPSJTcGFuaXNoIj4K PG1ldGEgbmFtZT0icmVzb3VyY2UtdHlwZSIgY29udGVudD0iZG9jdW1lbnQiPgo8bWV0YSBo dHRwLWVxdWl2PSJQcmFnbWEiIGNvbnRlbnQ9Im5vLWNhY2hlIj4KPG1ldGEgbmFtZT0iUmV2 aXNpdCIgY29udGVudD0iMTUgZGF5cyI+CjxtZXRhIG5hbWU9InJvYm90cyIgY29udGVudD0i YWxsIj4KPHN0eWxlIFRZUEU9InRleHQvY3NzIj4KICAgIEE6bGluayB7IHRleHQtZGVjb3Jh dGlvbjogbm9uZSB9CiAgICBBOnZpc2l0ZWQgeyB0ZXh0LWRlY29yYXRpb246IG5vbmUgfQog ICAgQTpob3ZlciB7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lIH0KPC9zdHlsZT4KPFND UklQVCBMQU5HVUFHRT0iSmF2YXNjcmlwdCIgVFlQRT0idGV4dC9qYXZhc2NyaXB0Ij4KICAg ICAgZnVuY3Rpb24gaXJBKG1lbnUpewogICAgICAgIGlmIChtZW51LnNlbGVjdGVkSW5kZXg+ MCkKICAgICAgICAgIHdpbmRvdy5sb2NhdGlvbi5ocmVmID0gbWVudS5vcHRpb25zW21lbnUu c2VsZWN0ZWRJbmRleF0udmFsdWU7CiAgICAgIH0KPC9TQ1JJUFQ+CjwvaGVhZD4KCjxib2R5 IGJnY29sb3I9IiNmZmZmZmYiIGxpbms9IiMwMDAwODAiIHZsaW5rPSIjMDAwMDgwIiBhbGlu az0iIzQwNDBGMCI+PGEgbmFtZT0idG9wIi8+CjxUQUJMRSBhbGlnbj0iQ0VOVEVSIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU4NCI+CjxU Uj4KPFREIFJPV1NQQU49IjIiIFdJRFRIPSI4OCI+PGEgaHJlZj0iLyI+PElNRyBhbHQ9IiIg Ym9yZGVyPSIwIiBzcmM9Ii9ncmFmaWNvcy9sb2dvcHJvZy5qcGciIHdpZHRoPSI4OCIgaGVp Z2h0PSIxMDYiPjwvYT48L1REPgo8dGQgYWxpZ249InJpZ2h0IiB2YWxpZ249Im1pZGRsZSIg Ymdjb2xvcj0iI0UzREZDQyI+PGEKICBocmVmPSIvbnVldmFfdXJsLnBocCI+PGZvbnQgc2l6 ZT0iMSIgZmFjZT0iVmVyZGFuYSI+QfFhZGlyIHVuYSBkaXJlY2Np8248L2ZvbnQ+PC9hPjxm b250CiAgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSI+IHwgPC9mb250PjxhCiAgaHJlZj0iL2N1 cnNvcy8iPjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPkN1cnNvczwvZm9udD48L2E+ PGZvbnQKICBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj4gfCA8L2ZvbnQ+PGEKICBocmVmPSIv YXJ0aWN1bG9zLyI+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSI+QXJ0JmlhY3V0ZTtj dWxvczwvZm9udD48L2E+PGZvbnQKICBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj4gfCA8L2Zv bnQ+PGEKICBocmVmPSIvZm9ybWFjaW9uLmh0bSI+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVmVy ZGFuYSI+Rm9ybWFjaSZvYWN1dGU7bjwvZm9udD48L2E+PC90ZD4KPC9UUj4KPFRSPgo8VEQg QUxJR049IkNFTlRFUiI+PHNjcmlwdCBsYW5ndWFnZT0nSmF2YVNjcmlwdCcKc3JjPSdodHRw Oi8vbGludXg1Lm5ldC9hZC9hZGpzLnBocD90YXJnZXQ9X2JsYW5rJndpdGhUZXh0PTAnPjwv c2NyaXB0PjwvVEQ+CjwvVFI+CjwvVEFCTEU+CjxUQUJMRSBhbGlnbj0iQ0VOVEVSIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU4NCI+CjxU Uj4KICA8VEQgYmFja2dyb3VuZD0nL2dyYWZpY29zL2xpbmVhMS5naWYnPjxJTUcgYWx0PScn IGJvcmRlcj0nMCcgaGVpZ2h0PScxMCcgc3JjPScvZ3JhZmljb3MvZW1wdHkuZ2lmJy8+PC9U RD4KPC9UUj4KPC9UQUJMRT4KCjx0YWJsZSBib3JkZXI9IjAiIHdpZHRoPSI1ODQiIGFsaWdu PSJjZW50ZXIiPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCIgdmFsaWduPSJ0b3AiPgo8VEFCTEUg Q0VMTFNQQUNJTkc9IjAiIENFTExQQURESU5HPSIwIiBCT1JERVI9IjAiPgo8VFI+CjxURCBB TElHTj0ibGVmdCIgV0lEVEg9IjEwMCUiIFZBTElHTj0idG9wIj48Rk9OVCBGQUNFPSJWZXJk YW5hLEFyaWFsLHNhbnNzZXJpZiIgU0laRT0iNCIgQ09MT1I9IiNhMGEzNTQiPjxTVFJPTkc+ Rm9yb3MgZGUgZGViYXRlPC9TVFJPTkc+PC9GT05UPgo8Zm9udCBmYWNlPSJ2ZXJkYW5hIiBz aXplPSIyIj4KPHA+PC9wPjxpbWcgc3JjPSJncmFmaWNvcy9jYXJwZXRhLmdpZiIgYWxpZ249 ImFic21pZGRsZSI+IDxiPkhUTUw8L2I+Cjxicj48YSBocmVmPSJmb3Jvcy5waHAiPkxpc3Rh IGRlIGZvcm9zPC9hPiB8IDxhIGhyZWY9ImhpbG9zLnBocD9maWQ9MiI+TGlzdGEgZGUgbWVu c2FqZXMgZGUgZXN0ZSBmb3JvPC9hPjxicj48YnI+CgoKPFRBQkxFIFdJRFRIPSIxMDAlIiBC T1JERVI9IjAiIENFTExQQURESU5HPSIwIiBDRUxMU1BBQ0lORz0iMCI+CjxUUj4KICA8VEQg QkdDT0xPUj0iIzAwMDAwMCI+CiAgICA8VEFCTEUgV0lEVEg9IjEwMCUiIEJPUkRFUj0iMCIg Q0VMTFBBRERJTkc9IjUiIENFTExTUEFDSU5HPSIxIj4KICAgIDxUUj4KICAgICAgPFREIEJH Q09MT1I9IiNFM0RGQ0MiPjxmb250IHNpemU9IjIiPjxiPkNvbW8gbGUgaGFnbyBwYXJhIHF1 ZSBzZSB2ZWEgZWwgZm9udCBxdWUgeW8gcHVzZTwvYj4KICAgICAgPEJSPkVudmlhZG8gcG9y IDxhIGhyZWY9Im1haWx0bzpzYWZ1bWVAdHV0b3BpYS5jb20iPlNBRlVNRTwvYT4gZWwgZCZp YWN1dGU7YSAxMSBkZSBtYXJ6byBkZSAyMDAyPC9URD4KICAgIDwvVFI+CiAgICA8VFI+CiAg ICAgIDxURCBCR0NPTE9SPSIjRkZGRkZGIj48Zm9udCBzaXplPSIyIj5Ib2xhLCANPGJyPgpu ZWNlc2l0byBheXVkYSBlbiBsbyBzaWd1aWVudGU6IHRlbmdvIG1pcyBwJmFhY3V0ZTtnaW5h cyBoZWNoYSBlbiBEcmVhbXdlYWJlciB5IGFncmVndSZlYWN1dGU7IGEgbGEgbGlzdGEgZGUg Zm9udCB1biB0aXBvIG51ZXZvIChuZXVyb3BvbCksIHRhbWJpZW4gaGljZSB1biBlc3RpbG8g Q1NTIGNvbiBlc2UgZm9udCB5IGFkanVudG8gbGEgaG9qYSBlbiBlbCB3ZWIgc2l0ZSwgcGVy byBhbCBtaXJhciBsYXMgcCZhYWN1dGU7Z2luYXMgZGVzZGUgUENzIHF1ZSBubyB0aWVuZW4g ZXN0ZSBmb250IGVuIHBhcnRpY3VsYXIgbm8gbG8gbXVlc3RyYSB5IHRvbWEgZWwgZGVmYXVs dCBxdWUgZXMgVGltZSBOZXcgUm9tYW4geSBzZSB2ZSBmZWlzaW1vLg08YnI+ClBlbnMmZWFj dXRlOyBlbiBjb2xvY2FybG9zIGNvbW8gZ2lmIG8gYWxnbyBhcyZpYWN1dGU7LCBwZXJvIHF1 aWVybyBzYWJlciAoc3Vwb25nbyBxdWUgbG8gaGF5KSBsYSBmb3JtYSBkZSBxdWUgc2UgdmVh IGVsIHRpcG8gZGUgZm9udCBxdWUgeW8gY29sb3F1JmVhY3V0ZTsgZW4gbWkgcCZhYWN1dGU7 Z2luYS4gIA08YnI+CnNpIGFsZ3VpZW4gbWUgcHVlZGUgYXl1ZGFyLCBncmFjaWFzLiA8L1RE PgogICAgPC9UUj4KICAgIDwvVEFCTEU+CiAgPC9URD4KPC9UUj4KPFRSPgogIDxURCBCR0NP TE9SPSIjRkZGRkZGIj48Zm9udCBzaXplPSIyIj48YSBocmVmPSJyZXNwb25kZXIucGhwP3Np ZD0yODIyJmZpZD0yIj5SZXNwb25kZXI8L2E+PGltZyBzcmM9ImdyYWZpY29zL3BlbmNpbC5n aWYiIGhlaWdodD0iMTMiIHdpZHRoPSIxNCI+PGJyPjxicj48L1REPgo8L1RSPgoKPC9UQUJM RT4KCjxUQUJMRSBhbGlnbj0iQ0VOVEVSIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjU4NCI+Cjx0cj4KICA8VEQgYmFja2dyb3VuZD0nL2dy YWZpY29zL2xpbmVhMS5naWYnPjxJTUcgYWx0PScnIGJvcmRlcj0nMCcgaGVpZ2h0PScxMCcg c3JjPScvZ3JhZmljb3MvZW1wdHkuZ2lmJy8+PC9URD4KPC90cj4KPHRyPgo8dGQgYWxpZ249 InJpZ2h0Ij48YSBocmVmPSIjdG9wIj48Zm9udCBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj5Q cmluY2lwaW8gUCZhYWN1dGU7Z2luYTwvZm9udD48L2E+PC90ZD4KPC90cj4KPHRyPgo8dGQg YWxpZ249ImNlbnRlciI+PCEtLSBDcmVkaXRvcyAtLT4KPGZvbnQgc2l6ZT0iMSIgZmFjZT0i VmVyZGFuYSI+JmNvcHk7IDE5OTktMjAwMiwKPC9mb250PjxhIGhyZWY9Im1haWx0bzpqYnJh dm9AcmV0ZW1haWwuZXMiPjxmb250CnNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPkpvYXF1aW4g QnJhdm88L2ZvbnQ+PC9hPjxmb250CnNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPiwgPC9mb250 Pgo8YSBocmVmPSJtYWlsdG86bXVsdGl2YWNAaW50ZXJuYXV0YXMub3JnIj48Zm9udCBzaXpl PSIxIgpmYWNlPSJWZXJkYW5hIj5EYW5pZWwgUm9kcmlndWV6PC9mb250PjwvYT48Zm9udCBz aXplPSIxIgpmYWNlPSJWZXJkYW5hIj4sCjxmb250IHNpemU9IjEiCmZhY2U9IlZlcmRhbmEi PkRhdmlkIENhcnJlcm88L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIKZmFjZT0iVmVyZGFuYSI+IHkg PGEgaHJlZj0ibWFpbHRvOmFsZXhtbUBpbmFtZS5jb20iPjxmb250IHNpemU9IjEiCmZhY2U9 IlZlcmRhbmEiPkFsZXggTW9yYWxlczwvZm9udD48L2E+PGZvbnQgc2l6ZT0iMSIKZmFjZT0i VmVyZGFuYSI+PGJyPgpQcm9ncmFtYWNpJm9hY3V0ZTtuIGVuIGNhc3RlbGxhbm8uPGJyPjwv Zm9udD48L3RkPgo8L3RyPgo8L1RBQkxFPgo8L2JvZHk+CjwvaHRtbD=9

1 0

RE: Updates to FFI spec
by Simon Marlow 13 Aug '02

13 Aug '02

> > At the moment, there are two kinds of initialisation done for each > > module: > > Both ELF and DLLs on Windows provide a way of specifying initializers. > > Or, easier yet, since the user is already using the hs_init function, > you could use that. The way you'd do that in ELF is to define a > special section 'hs_initializers'. Every module would contain a > single object in that section: the address of the initializer. (In > gcc you do this by attaching an attribute to the variable. In asm it > is even easier since assemblers directly expose sections to the > programmer.) The linker will do what it does with all sections: > concatenate the pieces from all object files. hs_init would treat the > section as an array of function pointers. I'm sure that the Windows > linker must have a similar mechanism - the main trick is figuring out > what name to give the sections. That's what I meant by a linker set :-) Cheers, Simon

1 0

RE: Updates to FFI spec
by Simon Marlow 13 Aug '02

13 Aug '02

> On 12-Aug-2002, Simon Marlow <simonmar(a)microsoft.com> wrote: > > > > I'd be equally happy (perhaps happier) if the header file spec was > > removed altogether. In a sense, this would leave the > Haskell part of a > > foreign binding even more portable, because it doesn't have > to specify > > the names of header files which might change between platforms. > > This is a C interface we're talking about, right? > > In C, the name of the header file is part of the API. > It doesn't change between different platforms unless > the API changes. > > Specifying the header name is essential if Haskell > implementations are to > ever apply any type-checking to these foreign interfaces. If > they don't, > then in practice I think Haskell programs using the FFI are > likely to be > less portable, and certainly more error-prone, since they will contain > type errors that may cause problems on one platform but not another. Specifying the header name is also essential for certain implementations (eg. GHC). I wan't suggesting not supplying the header file at all, just not supplying it in the foreign declaration and not defining it as part of the standard. But I take your point about the header file(s) being a proper part of the API. Cheers, Simon

1 0

RE: Library archives
by Simon Marlow 13 Aug '02

13 Aug '02

> > > (no, I'm not sure why they're in the C section of the FFI > > spec either). > > Because they are for implementing calls to C code in Haskell > that is compiled to .NET ILX. > > This doesn't mean that I want to necessarily defend them, > but this was the reason for their inclusion. Essentially, > SimonPJ was saying that to compile Haskell including "foreign > import ccall"s to .NET ILX, we need the library spec. > > I am not too fussed about .NET, so don't mind if we nuke the > [lib] specs (as Alastair already did in the CVS version of > the spec). Under .NET each DLL has its own namespace, so the [lib] spec is needed to disambiguate. Since it's a namespace issue, I'd feel better if on .NET the name of the C function took a different form (perhaps <lib>.<function>) and [lib] is removed from the spec. BTW I didn't know the spec was in CVS somewhere... where exactly? Cheers, Simon

3 2

RE: Proposed change to ForeignPtr
by Simon Marlow 12 Aug '02

12 Aug '02

> > What do you expect to happen if the finaliser calls a foreign > > exported function? > > Good question. > > I do not expect that to work on any platform that has difficulty > implementing newForeignPtr (because you could use it to implement > newForeignPtr). > > I don't know if it would be likely to work on GHC. > > I think the spec should say that it is an error or undefined > depending on whether GHC supports reentrant finalizers or not. Yes, it will work in GHC. makeForeignPtr is easily implemented in terms of newForeignPtr, using a foreign import "dynamic". > > That's a tricky one. From the standards point of view, I am > > actually *very* reluctant to introduce new names. On the other > > hand, reusing the old names will lead to a couple of unhappy emails > > from people using the old interface again. > > But only a couple I conjecture. Heh, I distinctly remember several complaints from *you* in the past when things have changed in GHC! Cheers, Simon

2 1

Updates to FFI spec
by Alastair Reid 11 Aug '02

11 Aug '02

For those not on the cvs mailing list: I've applied all the changes discussed over the last 2 moniths that received some support and no dissent. Changes since RC5: * Author list: changed Alastair Reid's institution * 4.1.1: Removed [lib] from impent syntax and discussion * 4.1.3: Added parentheses round FunPtr ft to make it easier to understand a tolerably complex type. * 4.1.4: Removed all mention of library objects * 6: Specified that HsBool==int in table2 Relabelled column 1 in table 3 (C symbol -> CPP symbol) Replaced 0 and 1 with HS_BOOL_FALSE/TRUE You will need this file: http://www.cse.unsw.edu.au/~chak/haskell/grammar.sty to build it. (I came close to adding this file to the repo but figured that Manuel must have a reason for not having done so himself.) Changes not applied: - I really, really want to resolve the ForeignPtr issues soon. http://www.mail-archive.com/ffi@haskell.org/msg00655.html http://www.mail-archive.com/ffi@haskell.org/msg00544.html http://www.mail-archive.com/ffi@haskell.org/msg00545.html - I'd like to see a standard way to call the GC from C http://www.mail-archive.com/ffi@haskell.org/msg00565.html Note that Hugs and GHC have had this for ages except that we call the function 'performGC' and there's no way to control how many generations are collected. - I see the question of Function prototypes as a portability problem waiting to happen. Either Hugs and GHC are right (you should use the user-supplied header file or NHC is right (you should ignore the header file). They can't both be right if we want portable code so the report should be clear about which one is right. (Given my druthers, I'd drop header files from the foreign import syntax and say that you have to specify it on the command line or propose that we standardize some variant of the GHCism {-# -include "foo.h" #-}. But I'm not excited enough about it to push hard for this.) - Changes to hs_init http://www.mail-archive.com/ffi@haskell.org/msg00539.html -- Alastair Reid alastair(a)reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

2 2

RE: Library archives
by Simon Marlow 11 Aug '02

11 Aug '02

> I see a lot of discussion about header files. > I see a small amount of discussion of libraries with many conflicting > suggestions. > I see no _conclusion_. Ok, I can't see the conclusion either, but I seem to recall that at one stage the library specs were removed from the spec altogether and only came back again because of .NET (no, I'm not sure why they're in the C section of the FFI spec either). >From the GHC perspective they're not useful, and it would be headache to implement them if we had to. Fortunately the current spec says that they are a "hint" only, so we don't have to implement them. But that causes problems for anyone wanting to write portable FFI code: by definition, because the interpretation of the lib spec is implementation dependent, it can't be used in portable code. So really, I think it should be removed. If the FFI spec says anything about libraries, IMHO it should say that the methods used to find and link against external libraries are implementation dependent. We as implementers can always get together and agree on a common mechanism (packages, command-line arguments, whatever) to make life easier for the punters. > ps In case it wasn't clear > yesterday, I think the spec should be > clear about whether C libraries live in local or global namespaces. > I propose that they should be in a single global > namespace. This will require no change to GHC but will require a change to > Hugs' historical behaviour. Fine by me. Cheers, Simon

4 3

Re: Proposed change to ForeignPtr
by George Russell 10 Aug '02

10 Aug '02

Alastair wrote [snip] > I propose the following changes: > > 1) Add these functions: > > makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO ForeignObj > attachForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () > > 2) Remove newForeignPtr and addForeignPtrFinalizer [snip] I don't understand this proposal. What is a ForeignObj? I call a C function, which gives me a cString :: Ptr CChar, and it's my responsibility to free it when I've finished with it. So I convert it to a ForeignPtr: foreignPtr <- mkForeignPtr cString and then always refer to the pointer via foreignPtr. When foreignPtr is garbage collected the space is freed. So how do I do this with your proposal?

2 1

Re: Storable tuples and what is 'alignment'?
by Alastair Reid 07 Aug '02

07 Aug '02

Redirected to ffi(a)haskell.org > 1) Why aren't there built in Storable instances for tuples? Writing > my own is a pain and in keeping with the 'up to 7tuple' limit, I > think built in instances would be nice Probably because we've no idea why you'd want to do it. The usual deal is that you want to interface to a C struct like this: struct pt { int x; int y; }; and want to access it from Haskell so you write something like: type Pt = (CInt,CInt) instance Storable Pt where alignment = #const alignOf(struct pt) sizeOf = #const sizeof(struct pt) peek p = do x <- peek (p + #const(offsetOf(struct pt, x))) y <- peek (p + #const(offsetOf(struct pt, y))) return (x,y) poke ... = ... That is, for each C type you encounter, you write a custom instance. An important thing about this is that you're definitely using the right offset to access the field - there's nothing in the C standard that requires the obvious relationship between alignment/size and offset to hold. So what are you doing that needs Storable instances for arbitrary tuples? -- Alastair Reid alastair(a)reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

2 1

RE: Storable tuples and what is 'alignment'?
by Simon Marlow 07 Aug '02

07 Aug '02

[ moved to ffi(a)haskell.org ] > You also need to allow for any padding which is required to satisfy > the alignment constraints of b, e.g. > > sizeOf (a,b) = sizeOf a + padding (a,b) + sizeOf b > where padding (a,b) = (alignment b - sizeOf a > `mod` alignment b) `mod` alignment b > > > alignment (a,b) = alignment a + alignment b > > The alignment of the overall structure is determined by the alignment > of the first element. Subsequent elements are aligned (if necessary) > by the addition of padding between elements. > > alignment (a,_) = alignment a I think in fact that the aligment of the whole structure should be alignment (a,b) = alignment a `max` aligment b which would mean that sizeOf should be defined as sizeOf (a,b) = sizeOf a + padding + sizeOf b where b_align = alignment b padding = case sizeOf a `mod` b_align of 0 -> 0 n -> b_align - n consider for example struct { int a; double b } on a 32-bit architecture where doubles must be aligned on an 8-byte boundary (eg. Sparc), gcc will always align the structure on an 8-byte boundary and put 4 bytes of padding between the elements. Cheers, Simon

2 1