Version française
Home     About     Download     Resources     Contact us    
Browse thread
Safe Obj.magic container ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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