Re: [Caml-list] segfault in simple program with 4.02 native

["Frédéric Bour" <frederic.bour@lakaban.net>]

Since it is generated code and offsets of the fields are already known,
Obj.new_block / Obj.set_field / Obj.repr could do it too.
The Obj.repr will be the only point were the typed version is introduced 
and it won't receive any mutation after that, this should be enough to 
make it works.

Of course, this might not be robust against future changes.

On 06/09/2014 10:00, Milan Stanojević wrote:
> Could you do a dirty trick where you define a record that is the same
> as the one you have now except that is has mutable fields, then you do
> your parsing like now and then at the end return a record with
> immutable fields (using (Obj.magic mutable : immutable)? You just need
> to make sure that your mutable record doesn't escape your code.
>
> On Sat, Sep 6, 2014 at 1:51 AM, Martin Jambon
> <martin.jambon@ens-lyon.org> wrote:
>> On Fri 05 Sep 2014 05:12:44 PM PDT, Jeremy Yallop wrote:
>>> On 6 September 2014 00:39, Martin Jambon <martin.jambon@ens-lyon.org>
>>> wrote:
>>>> That code is generated by atdgen. What happens is that we have to either
>>>> create an empty record when starting to parse a list of unordered JSON
>>>> fields, or use a bunch `let <field name> = ref None in` for each field
>>>> and
>>>> create the record in the end. While the latter approach is not much more
>>>> work to implement, the resulting code was found to be significantly
>>>> slower.
>>>>
>>>> The reason why it's using `Obj.magic 0.0` is that it worked in all cases
>>>> (and has been for the past 4 years). Obtaining a well-formed constant
>>>> value
>>>> for any type is not trivial, so this what we have.
>>>>
>>>> It's very possible that it's now broken with OCaml 4.02. First try a
>>>> 'make
>>>> test' from atdgen's source directory (https://github.com/mjambon/atdgen)
>>>> and
>>>> see if it passes.
>>>
>>> It does seem to be broken, and the change in behaviour with 4.0.2 is
>>> apparently due to improved constant propagation
>>> (http://caml.inria.fr/mantis/view.php?id=5779).
>>>
>>> The compiler now takes more advantage of immutability to improve the
>>> memory usage and performance of programs.  It's safe (or ought to be
>>> safe) to assume that immutable record fields are never updated, so the
>>> values used to initialize the fields can be propagated to other parts
>>> of the program.  Here's a small example that shows the change in
>>> behaviour between 4.01 and 4.02.
>>>
>>>      type t = { s : string }
>>>      let x = { s =  "one" }
>>>      let () = Obj.(set_field (repr x) 0 (repr "two"))
>>>      let () = print_endline x.s
>>>
>>> Using OCaml 4.01 the third line overwrites the field 's'  and the
>>> fourth line reads the updated field and prints "two".  Using OCaml
>>> 4.02 the initial value of the field is propagated past the write to
>>> the code in the fourth line, so the program prints "one".
>>>
>>> The code currently generated by atdgen assumes that it's safe to treat
>>> fields as if they were mutable -- that is, it assumes that it's safe
>>> to initialize a field with a value of the wrong type, so long as the
>>> value is overwritten before the field is first read.  I don't think
>>> such tricks were ever explicitly guaranteed to work, but they're now
>>> much more likely to fail, leading to the dummy initial value being
>>> accessed at an inappropriate type.
>>
>> Thanks for the explanation, Jeremy. I guess atdgen will have to use "option
>> refs" after all unless someone has a better idea.
>>
>> ATD definition:
>>
>> type t = {
>>   ?field0: foo option;
>>   ~field1: string;
>>   field2: int;
>> }
>>
>> Generated OCaml code:
>>
>> let field0 = ref None in
>> let field1 = ref "" in
>> let field2 = ref None in
>> ...
>> (* parse json fields coming in an unknown order *)
>> ...
>> {
>>   field0 = !field0;
>>   field1 = !field1;
>>   field2 = (match !field2 with None -> error ... | Some x - >x);
>>
>> }
>>
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs