Version française
Home     About     Download     Resources     Contact us    
Browse thread
SafeUnmarshal: questions/problems/timings
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Hendrik Tews <tews@c...>
Subject: SafeUnmarshal: questions/problems/timings
Dear all,

I used the safeUnmarshal module
(http://www.pps.jussieu.fr/~henry/marshal/) in order to check if
some marshaled ocaml data is compatible with its type (the data
is generated in a mixed C++/ocaml program). Here are my
experiences:

1. I made some measurements that suggest that the 
   unmarshal has quadratic complexity in the data size, see

   http://www.cs.ru.nl/~tews/marshal-plot.eps
   http://www.cs.ru.nl/~tews/marshal-plot-detail.eps

   If my (simple-minded) estimations are correct it would take
   more than 2 hours to check 4 MB of marshaled data (which I
   generate in less than 3 seconds).

   Is there any hope that the time complexity will improve?


2.	    Objective Caml version 3.09.3+dev0+ty1

    # SafeUnmarshal.copy [^nativeint^] 4;;
    Segmentation fault


3. Would it be possible to put an english version of
   http://www.pps.jussieu.fr/~henry/marshal/docTy/Ty.html online?


4. Instead of type-safe unmarshal functions, I am more interested
   in checking if some value that has been constructed outside
   ocaml is type correct. Therefore I would suggest to make
   Check.check available in come way. I am using now

     let check obj ty = Check.check (Obj.repr obj) (Ty.dump ty)

   with type 

     val check : 'a -> 'a tyrepr -> bool

   Am I right that the type parameter of tyrepr is a kind of
   phantom type that is mainly used to restrict the type of
   SafeUnmarshal.from_channel? Then I could also use 

     val check : 'a -> 'b tyrepr -> bool  ?

   It would be great if (as a debugging feature) this check could
   produce some sort of trace that helps to locate those parts
   that violate the given type.

5. nativeint, int32, and int64 are not supported yet (I would
   suggest to make the documentation a bit more precise in that
   point). As fix I use (in Check.check_block):

    | Tnativeint -> 
	tag = Obj.custom_tag && size = 2 && 
	((Obj.field obj 0) == (Obj.field (Obj.repr Nativeint.zero) 0))
    | Tint32 ->
	tag = Obj.custom_tag && size = 2 && 
	((Obj.field obj 0) == (Obj.field (Obj.repr Int32.zero) 0))
    | Tint64 ->
	tag = Obj.custom_tag && size = 3 && 
	((Obj.field obj 0) == (Obj.field (Obj.repr Int64.zero) 0))

   Any comments? On a 64 bit architecture the int64 size should be
   required to be 2.

   I would strongly suggest to replace the catch all cases

    | _ -> false

   in check.ml with some more precise code (it took me several
   hours of bug hunting until I found out that the above line
   made my unmarshal fail without even looking at the
   nativeints). 


6. Thanks for SafeUnmarshal, it helped me a lot when checking the
   data created inside C++!


Bye,

Hendrik