On Mon, May 13, 2002 at 04:20:35PM +0900, Jacques Garrigue wrote:
> Yes, NULL is valid, as are all word-aligned addresses outside of the
> Caml heap.

This probably ought to be mentioned in the manual... Unless there's a
perlish "the implementation is the specification" -attitude with ocaml.

> Of course it should be given an abstract type, since there is nothing
> you can do with it inside Caml.
>
> Note however that the statement about "memory allocated by malloc"
> being safe is to be taken carefully, since people have already
> reported strange bugs with the following scenario:
> 
> * allocate a data structure with malloc
> * get a direct pointer to it in caml
> * free the structure
> * expand the caml heap, unfortunately including the free-ed malloc block
> * your pointer is now seen as a pointer inside the caml-heap,
>   and followed by the GC, directly into a segmentation fault...
> 
> This is a rather improbable scenario, but better know it in advance.

The moment you free a structure without being absolutely certain that there
are no references to it anywhere in caml world, you are already asking for
trouble, so this isn't much of an additional setback.

> Better to limit direct pointers to structure that are not going to be
> free-ed, and use boxed ones otherwise.

Actually, I was going to use abstract-tagged blocks. I noticed, though, that
allocating them is a bother, since you have to calculate the size in fields
manually: (size + sizeof(value) - 1) / sizeof(value). An allocation function
for abstract blocks that takes a size in _chars_ would be a convenient
addition to alloc.h. Or even a macro that takes a type t and returns a
block of sizeof(t) casted to t*.

Also, there seems to be no direct way of getting the actual raw data pointer
for an abstract value v. Of course you can do (t*)v, but is that "portable"
in the sense of guaranteed by the FFI? I noted that in mlvalues.h there is a
macro Bp_val(v) that returns the pointer to data as char*, but this is not
mentioned in the manual, so I'm wondering whether this is a part of the FFI
or an implementation detail? The Correct way to do this at the moment seems
to be (t*)&Field(v, 0), which is not very clear and kind of lengthy.

I guess I'm just being a bit pedantic, coming from the Haskell world where
the FFI has (soon) a real implementation-independent specification...


Lauri Alanko
la@iki.fi
-------------------
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