Browse thread
[Caml-list] NULL as a caml value
-
Lauri Alanko
-
Jacques Garrigue
- Christopher Quinn
- Lauri Alanko
-
Jacques Garrigue
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-05-14 (07:41) |
From: | Lauri Alanko <la@i...> |
Subject: | Re: [Caml-list] NULL as a caml value |
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