Browse thread
Safe Obj.magic container ?
[
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: | -- (:) |
| From: | Richard Jones <rich@a...> |
| Subject: | Re: [Caml-list] Safe Obj.magic container ? |
On Thu, Feb 28, 2008 at 11:20:53AM -0800, Jake Donham wrote: > On Thu, Feb 28, 2008 at 6:23 AM, Damien Doligez <damien.doligez@inria.fr> > wrote: > > > Example (on a 32-bit machine): > > > > Objective Caml version 3.10.2+rc1 > > > > # let x = Obj.repr 1;; > > val x : Obj.t = <abstr> > > # let y = Obj.repr 1.0;; > > val y : Obj.t = <abstr> > > # [| x; y |];; > > - : Obj.t array = [|<abstr>; <abstr>|] > > # [| y; x |];; > > Bus error > > > Could you please explain this behavior? I _think_ this is what's going on: Obj.repr is just the %identity primitive. So 'x' and 'y' still look like an int and a float respectively to the garbage collector. ie. 'x' is still shifted left 1 place with the bottom bit set. 'y' is still a pointer to a boxed 8 bit float (with a header on the heap identifying it as such). Constructing the array calls the caml_make_array primitive, which looks at the tag of the first element to see if it's a float. This would cause the unboxing optimization. Unfortunately if caml_make_array spots the possible unboxing of an array of floats, then it blindly copies the remaining elements, which dereferences the int (thinking it's a pointer to a float) and that causes the segfault. This also explains why it works the other way around, because having the int first doesn't trigger the optimization. Rich. -- Richard Jones Red Hat