Marshal and magic_copy in js_of_ocaml

Question

New question. I am looking through the very enjoyable Ocaml ORA . When I went to play with the magic_copy example from the Marshal section, I was closer to the browser than to the terminal, so I tried it in ocsigen toplevel in the browser , where I was surprised to get the result:

(* js_of_ocaml *) # let ora_magic_copy a = let s = Marshal.to_string a [Marshal.Closures] in Marshal.from_string s 0;; val ora_magic_copy : 'a -> 'b = <fun> # (ora_magic_copy 2 : float) +. 3.1;; - : float = 5.1 

Checking that something has changed between ocaml 2 (the current version when the book was written) and ocaml 3.12.1 used by the add-on installed on my machine and js_of_ocaml, I tried the same example in the usual toplevel installed on my machine and got the result explained in the book: segfault due to problems with the system with checking marshaled values.

  (* Linux toplevel *) # (ora_magic_copy 3: float) +. 2.1;; Segmentation fault (core dumped) 

I'm just wondering: why?

I see that in three cases Marshal.to_string gives the same line: linux marshalling int, js_of_ocaml marshalling and int, js_of_ocaml sorts the float. Odd user - linux toplevel sorting a float.

Is this related to something about js_of_ocaml using basic javascript types? Or just ... undefined behavior?

Answer 1

Yes, your problem arises from the fact that you are testing for javascript toplevel.

When you use standard ocaml toplevel, operation +. works with OCaml floats, i.e. with a double block inside a block, two parameters are expected +. will be pointers to such fields. In your example, instead of a pointer, you specify an integer OCaml 2 (internally it is represented as 5, i.e. 2 <1 + 1), so OCaml segfaults when trying to read a double, which should be in position 0x5 in memory ...

In the js_of_ocaml browser js_of_ocaml floats are just javascript floats, and integers are javascript integers, and +. is a javascript add-on that can add integers and float (by automatically converting integers to float), since the values ​​are marked with their types.