Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] CamlDL/Abstract pointers problem
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] CamlDL/Abstract pointers problem
From: Richard Jones <rich@annexia.org>
> On Thu, Jan 29, 2004 at 08:55:16PM +0100, Alain.Frisch@ens.fr wrote:
> > Reference: http://pauillac.inria.fr/~doligez/caml-guts/Fahndrich99.txt
> 
> Interesting.  Can someone who knows about the guts of OCaml comment on
> this: Does OCaml store simply the start and extent of the "ML Heap"?
> Or does it know about individual blocks of ML heap and use some sort
> of tree structure to work out if a pointer points into the heap?
> 
> I could imagine a scenario like this:
> 
> +---------+
> | ML      |
> | Heap    |
> |         |
> |    ---------\
> |         |   |
> +---------+   |
>               |
> +---------+   |
> | C       |<--/
> | malloc  |
> +---------+
> 
> +---------+
> | More    |
> | ML      |
> | Heap    |
> |         |
> +---------+
> 
> If OCaml only knew about the start and extent of the ML heap, then it
> might think that the pointer to the C-allocated space lies within the
> ML heap.

Fortunately, ocaml is clever enough to properly determine what is the
ML heap.
However, there is another scenario which could cause you problems:
if for some reason your C pointer get freed, and later the ML heap is
extended so that it includes the address of the pointer, then you may
have some pointers left on the ML which will now be seen as ML
pointers.

 +---------+
 | ML      |
 | Heap    |
 |         |
 |    ---------\
 |         |   |
 +---------+   |
               |
 +---------+   |
 | More ML |<--/
 | Heap    |
 +---------+

Some people have got problems with that.
So the safe rule is: only use "raw" C pointers (not wrapped in a
custom block) when you are sure the pointed block will not be freed.
But this is self-evident: if the pointed block is managed, then you
should probably have a custom block to cooperate with C memory
management anyway.

           Jacques Garrigue

-------------------
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