[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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