[Caml-list] Using C values in ocaml code

[Caml-list] Using C values in ocaml code

[Tomasz Zielonka]

Hi

I'm linking ocaml code with a program written in C. I want to use
some C type values within ocaml code (store in structures, pass around,
apply to external functions, etc.). Below is a simplified example:

  type cvalue

  external get_some_value : unit -> cvalue = "get_some_value"
  external process_value  : cvalue -> cvalue = "process_value"

example C primitive:

  value
  get_some_value(value unit)
  {
    CAMLparam1(unit);
    Datum x;
    x = foo();
    CAMLreturn((value) x)
  }

What I'm afraid of is: 
  Can there be any problem with Garbage Collector
... if cvalue is word aligned pointer? (I think I'll be ok)
... if cvalue can have any value?

My situation is that cvalue is word with any value possible - eg. it
can be a pointer or an integer.

Do I have to put it in a custom block or something?

tom

-- 
   .-.   Tomasz Zielonka                           CYBER SERVICE
   oo|   programista                        http://www.cs.net.pl
  /`'\   zielony@cs.net.pl
 (\_;/)  tel: [48] (22) 723-06-79 | tel/fax: [48] (22) 723-01-75
-------------------
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

Re: [Caml-list] Using C values in ocaml code

[Markus Mottl]

On Thu, 31 Jan 2002, Tomasz Zielonka wrote:
>   value
>   get_some_value(value unit)
>   {
>     CAMLparam1(unit);
>     Datum x;
>     x = foo();
>     CAMLreturn((value) x)
>   }

You can't just cast 'x' to an OCaml-value: if it is an integer, you'll
have to use the "Val_int"-macro. Otherwise the integer might exceed the
range allowed by OCaml and could be interpreted as a pointer by the GC,
possibly resulting in a crash (integers need to be tagged).

If it is a pointer to something allocated by C, you could return it
directly, but this may cause troubles if you deallocate this region of
memory while the value is still reachable from the OCaml-world (read
section 17.2.3 to learn what can happen).

Therefore you should use a more appropriate encoding. If you don't want
the GC to notify your C-program that the value is not reachable from your
program anymore (i.e. can be finalized/deallocated), then just allocate
a block tagged abstract of size 1, e.g:

  value v = alloc_small(1, Abstract_tag);

and write your pointer into its (only) field using the Field-macro:

  Field(v, 0) = foo();

The above works with integers (no need for conversions then), too, btw.

If you want to have a function for finalization/deallocation called by
the GC but don't want to handle custom blocks in their full generality,
just use "alloc_final". It allows you to pass a finalization function
+ some GC-parameters and creates a custom block with the other custom
functions (hashing, etc.), set to default values.

See the manual for details...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: [Caml-list] Using C values in ocaml code

[Tomasz Zielonka]

On Thu, Jan 31, 2002 at 12:12:51PM +0100, Markus Mottl wrote:

> You can't just cast 'x' to an OCaml-value: if it is an integer, you'll
> have to use the "Val_int"-macro. Otherwise the integer might exceed the
> range allowed by OCaml and could be interpreted as a pointer by the GC,
> possibly resulting in a crash (integers need to be tagged).

It's even more fun. Odd ints would be interpreted as ints with halved
value, even ints as pointers.

from mlvalues.h:

#define Is_long(x)   (((x) & 1) != 0)
#define Long_val(x)     ((x) >> 1)
#define Int_val(x) ((int) Long_val(x))

> If it is a pointer to something allocated by C, you could return it
> directly, but this may cause troubles if you deallocate this region of
> memory while the value is still reachable from the OCaml-world (read
> section 17.2.3 to learn what can happen).

Both - an integer or a pointer.  It is not always possible to check
whether it is a pointer or an integer not knowing the context. 

> Therefore you should use a more appropriate encoding. If you don't want
> the GC to notify your C-program that the value is not reachable from your
> program anymore (i.e. can be finalized/deallocated), then just allocate
> a block tagged abstract of size 1, e.g:

I will use abstract block then.

Thanks,
Tom

-- 
   .-.   Tomasz Zielonka                           CYBER SERVICE
   oo|   programista                        http://www.cs.net.pl
  /`'\   zielony@cs.net.pl
 (\_;/)  tel: [48] (22) 723-06-79 | tel/fax: [48] (22) 723-01-75
-------------------
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

Re: [Caml-list] Using C values in ocaml code

[Markus Mottl]

On Thu, 31 Jan 2002, Tomasz Zielonka wrote:
> On Thu, Jan 31, 2002 at 12:12:51PM +0100, Markus Mottl wrote:
> > You can't just cast 'x' to an OCaml-value: if it is an integer, you'll
> > have to use the "Val_int"-macro. Otherwise the integer might exceed the
> > range allowed by OCaml and could be interpreted as a pointer by the GC,
> > possibly resulting in a crash (integers need to be tagged).
> 
> It's even more fun. Odd ints would be interpreted as ints with halved
> value, even ints as pointers.

Yes, but since you were using an abstract type in the "external"
declaration, you wouldn't have been able to add things within OCaml
anyway. As long as the GC hadn't gone mad and killed the process, you'd
have had to do computations within C-functions.

> Both - an integer or a pointer.  It is not always possible to check
> whether it is a pointer or an integer not knowing the context. 
> 
> I will use abstract block then.

This would be the best choice if you can't know the type of the C-value,
if finalization is not needed and if handling of integers and pointers
should be generic. Usually, you'll want to specialize the handling of
integers and also unboxed floats whenever possible to improve performance
(no indirection to access values).

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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