module thinning in Caml 1.06

module thinning in Caml 1.06

[Scott Alexander]

For my active networks work, I'm using Dynlink to dynamically load modules.  In
the same way as MMM, I'm using module thinning to ensure that loaded modules
cannot do "bad" things.  Thus, I have a Safeunix.mli which is a very heavily
thinned version of Unix.mli.  (It is, of course, derived from the MMM module
of the same name.)  In Caml 1.05, I was able to say:

type sockaddr = Unix.sockaddr =
    ADDR_UNIX of string
  | ADDR_INET of inet_addr * int
  | ADDR_PKT of int * string * int

which gave me a type Safeunix.sockaddr.  With this, I was able to define
a function which returned the return value from Unix.sendto (a
Unix.sockaddr) and call it a Safeunix.sockaddr.

Under 1.05, if I then compiled a module which opens Safeunix, Safeunix
would be in its list of required interfaces (as reported by objinfo),
but Unix would not.  Under 1.06, Unix is now a required interface, so I
am unable to link.  Is there a way around this short of writing a
function to convert the types that I can get my code working again with
1.06.  (It seems unnecessarily inefficient to run the conversion function
for each call.)

Thanks,
Scott Alexander
salex@dsl.cis.upenn.edu

Re: module thinning in Caml 1.06

[Francois Rouaix]

Hi,

> Safeunix.mli:
> type sockaddr = Unix.sockaddr =

> Under 1.05, if I then compiled a module which opens Safeunix, Safeunix
> would be in its list of required interfaces (as reported by objinfo),
> but Unix would not.  Under 1.06, Unix is now a required interface, so I
> am unable to link.

The definition of "the list of required interfaces", implicitly guaranteeing
type-safe linking, has varied quite a lot in version 1.03, 1.05 and 1.06.
The full details of the story behind this are tedious. It seems, however,
that we have now reached a stable point where the computation of this list
is well understood and indeed guarantees type-safe linking (including with
Dynlink); this was not necessarily the case in previous versions of OCaml...

>From a practical point of view, when one wants to do "safe dynamic linking"
in the presence of possibly hostile bytecode, there is now only one way to
go:

1- write safe*.mli interfaces WITHOUT any reference to the original signatures,
and in particular WITHOUT type equality constraints.
The idea of using equality constraints was that you could build "towers" of
safe libraries, ie that you could write
module Unix : SafeUnix
module Foo : SafeFoo
where Foo would open Unix and SafeFoo would open SafeUnix.
The compiler had to know that SafeUnix.t = Unix.t in order to accept
that Foo : SafeFoo, if type t was used in the signature of Foo and exported
in SafeFoo.
This doesn't work anymore, as you noticed, and it will never work like before
if we want to keep guaranteeing type safe linking.

If you have only one single safe*.ml, there is no need to write equality
constraints anyway. This is just type abstraction (albeit with explicit
type definitions).
If you have multiple safe libraries, then you should:

2- catenate all safe*.mli into one single safe.mli interface (and proceed
similarly for .ml files). Compile this single safe module, and make it
available for dynlinked files. Remember that you can keep as much
module hierarchy as you need.

This is how the applet system is built in the current version of MMM
(due to be released RSN, BTW). There is a single large safe module build with
safestd (abstraction of Pervasives), safetk and friends, safestr, safeunix,
safeapplets, etc...
The applet opens Safe, and finds inside Tk, Str, Unix (the thinned versions),
etc... 

Hope it helps,
(and I realize this may be a bit confusing for the reader who has probably
never encountered this problem)

--f