From: Richard Jones <rich@annexia.org>
To: Jake Donham <jake.donham@skydeck.com>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Safe Obj.magic container ?
Date: Thu, 28 Feb 2008 23:19:35 +0000 [thread overview]
Message-ID: <20080228231935.GA26592@annexia.org> (raw)
In-Reply-To: <c7e4e9f0802281120v4994fdecj3b76e3f386621961@mail.gmail.com>
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
next prev parent reply other threads:[~2008-02-28 23:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-27 9:09 David Teller
2008-02-27 9:43 ` [Caml-list] " Luc Maranget
[not found] ` <37B36607-9F22-4537-B4DB-1E04348E2B90@inria.fr>
2008-02-28 14:23 ` Damien Doligez
2008-02-28 15:29 ` David Teller
2008-02-28 16:24 ` Damien Doligez
2008-02-29 1:52 ` Jacques Garrigue
2008-02-29 8:18 ` David Teller
2008-02-28 19:20 ` Jake Donham
2008-02-28 23:19 ` Richard Jones [this message]
2008-02-27 11:23 ` Tom Primožič
2008-02-27 21:22 ` David Teller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080228231935.GA26592@annexia.org \
--to=rich@annexia.org \
--cc=caml-list@inria.fr \
--cc=jake.donham@skydeck.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox