Am Mon, 2004-07-12 um 05.39 schrieb John Prevost:
> You shouldn't have to package up a non-caml managed pointer in any
> sort of caml structure at all.  Take a look at section 18.6 of the
> manual, specifically the definitions of curses_initscr and
> curses_wrefresh.  Any pointer that's outside the caml heap (that is,
> pretty much any pointer that you're getting from a non-caml function)
> can simply be treated as opaque, and you can use Caml's type system to
> make sure it's valid (as long as the C code always handles these
> pointers correctly.)

In principle, this is correct, but there are traps. For example,
consider the case the memory block is freed by the C routine, and the
same block is allocated by the caml runtime. In this case, the pointer,
once outside the caml heap, is now inside, and the GC crashes. Because
of this, I would not recommend this technique. Custom blocks (or int32
blocks) are risk-free in this regard.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners