Sigbjorn Finne wrote:
> But this relies on discipline on the part of the user

Well, even requiring the usage of foreign objects instead of bare
Addrs has something to do with discipline.   :-]

> - do you want it to mysteriously fail if you second guessed wrongly
> and left out the allocation of a stable ptr?

If you use bare Addrs, your memory usage probably grows mysteriously.

In a nutshell: This thread is slowly drifting to more religious areas.
On the one hand Manuel wants a minimalistic approach with simple
rules, Sigbjorn/Marcin on the other hand want an easy to use and
efficient way to pass foreign objects. If they are compound objects
or not depends on one's personal view I think.

I'd like to finish discussion around the low-level aspects of the
FFI, so I propose the following: If none of the implementors yells
loudly that the ForeignObj FFI rule is costly to implement, this
lifetime rule should be left as it is. (It can't be hard to implement,
because as a fallback the StablePtr "trick" could be used.) We all
agree that it is easy and safe to use, and captures a common case.
But we still need foreignObjToAddr for marshaling compound structures.

Marcin 'Qrczak' Kowalczyk wrote:
> Mon, 21 Feb 2000 11:57:18 +0100, Sven Panne <[EMAIL PROTECTED]> 
>pisze:
> > [...] What e.g. about stable pointers? Should they be dereferenced
> > automatically or not?
> 
> No, because I want to pass them around in the C world, store in them
> in C data structures and pass them back to Haskell later. (Yes, really.)

OK, that was a silly example from me. :-} Apart from keeping things
alive, using them in Haskell callbacks is their only usefulness.

> > Should memory allocated for passing Strings be deallocated after
> > a foreign call or not?
> 
> It depends, so the place for it is in a library. But a default most
> common behavior could be built into FFI as well: it would have '\0'
> at the end and stay alive until the called function returns.

Uh, oh, no! There is no "common" case here, e.g. anybody remembers the
XView toolkit? The rules when deallocation for strings was allowed
and when not were extremely chaotic, and I bet there are lots of
libraries around where there is no simple rule, either. So this should
really be made explicit by the programmer via a FFI library.

Cheers,
   Sven
-- 
Sven Panne                                        Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik                     FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen              Oettingenstr. 67
mailto:[EMAIL PROTECTED]            D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne

Reply via email to