* Re: [Caml-list] Ocaml ffi release 1.2.2
@ 2001-08-20 22:23 Jean-Marc Eber
2001-08-20 21:42 ` David Fox
0 siblings, 1 reply; 3+ messages in thread
From: Jean-Marc Eber @ 2001-08-20 22:23 UTC (permalink / raw)
To: caml-list, dsfox
I think that new versions of ocamlffi should also
be regularly announced at the caml list.
Anything that helps, secures or simplifies the interface
between OCaml and other languages/systems is
important help for most of us!
As a reader of the (now unmoderated) caml list, I
always appreciate this kind of announcements.
By the way, great thanks to the Inria folks that are
reorganising and updating the Caml Hump page!
Jean-Marc Eber
-----Original Message-----
From: dsfox@cogsci.ucsd.edu <dsfox@cogsci.ucsd.edu>
To: caml-list@inria.fr <caml-list@inria.fr>
Date: dimanche 19 août 2001 20:22
Subject: [Caml-list] Ocaml ffi release 1.2.2
>I've released a new version of the foreign function generator. Future
>releases will be announced at the sourceforge project page, which can
>be reached through http://ocamlffi.sourceforge.net.
>-------------------
>Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
>To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
>
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Caml-list] Segfault in a native code multi-threaded program
@ 2001-08-19 0:24 John Gerard Malecki
2001-08-19 18:18 ` [Caml-list] Ocaml ffi release 1.2.2 dsfox
0 siblings, 1 reply; 3+ messages in thread
From: John Gerard Malecki @ 2001-08-19 0:24 UTC (permalink / raw)
To: caml-list
John Max Skaller wrote (2001-08-19T09:15:44+1000):
>
> > <hint for next ocaml ;)>
> >
> > It would be very nice to be able to rely on Marshal as safely as on
> > ocaml typing. Just to be sure that if I expect an int * string, I will
> > effectively receive an int * string or raise an exception. It could
> > probably be done using the same tricks as used in printf formatters.
> >
> > </hint for next ocaml ;)>
>
> As I understand it, this is a non-trivial research problem.
Yes it is but in the mean-time we are stuck with the problem. I'll
describe the IMPERFECT solution i use. If anyone else has something
better please do describe it.
The idea is to use the already existing extract_crc program to get the
digest of the data-structure to be written. There are obvious flaws
including the fact that the value to be written must have a concrete
signature and the programmer must ensure that all of the accessible
signatures are included. Assuming that one didn't make any mistakes
this should catch reading an "out of version" marshaled value.
Here is the text from an email i wrote a while ago describing the same
mechanism followed by all of the code to make a working example.
Under some assumptions about the things that you are writing out
extract_crc can provide some support. The flaw is that extract_crc is
not "deep". If you create a single .mli file which only contains the
signature of the value you are to write then you can, with some
additional makefile complexity, automatically generate an extract_crc
.ml from that .mli file. For example, here is the output from
extract_crc of the cell.mli file
let crc_unit_list = [
"Cell",
"\032\036\180\144\173\052\208\140\081\102\211\172\198\229\098\218"
]
Instead of simply doing an output value you could ALWAYS do an output
value of crc_unit_list and then execute
let safe_output_value safe oc data =
output_value oc safe;
output_value oc data
let safe_input_value safe ic =
let safe_input = input_value ic in
if safe_input = safe then
input_value ic
else
raise (Sys_error "safe_input_value")
The majority of the work is in (makefile) procedures for automatically
generating the crc_unit_list. One must be careful about the
dependencies to make sure that the makefile can both bootstrap and
always keep the crc_unit_list file up to date.
At one time i thought of using the dynlink module to solve these
problems but it turns out that there is no real advantage as the
majority of the work is in the makefile.
Here is a sample Makefile
RESULT := a.out
SOURCES := safety.ml test.ml
all: safety.ml byte-code
include OcamlMakefile
EXTRACT_CRC := $(shell $(OCAMLC) -where)/extract_crc
safety.ml: test.cmi
$(EXTRACT_CRC) test > $@
check: all
OCAMLRUNPARAM='b=1' ./$(RESULT)
The file test.mli
type t = (int * int) list
and the file test.ml
type t = (int * int) list
let safe_output_value safe oc data =
output_value oc safe;
output_value oc data
let safe_input_value safe ic =
let safe_input = input_value ic in
if safe_input = safe then
input_value ic
else
raise (Sys_error "safe_input_value")
let _ =
let data = [ 0,0; 1,1 ] in
let oc = open_out_bin "test.db" in
safe_output_value Safety.crc_unit_list oc data;
close_out oc
let _ =
let ic = open_in_bin "test.db" in
let data = safe_input_value Safety.crc_unit_list ic in
close_in ic;
data
-cheers
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-08-20 21:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-20 22:23 [Caml-list] Ocaml ffi release 1.2.2 Jean-Marc Eber
2001-08-20 21:42 ` David Fox
-- strict thread matches above, loose matches on Subject: below --
2001-08-19 0:24 [Caml-list] Segfault in a native code multi-threaded program John Gerard Malecki
2001-08-19 18:18 ` [Caml-list] Ocaml ffi release 1.2.2 dsfox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).