On Sat, 2013-05-25 at 11:09 +0100, Thomas Leonard wrote:
> Hi,

Hi!

> I'm trying to interface to some C code which uses a lot of structs. I
> can declare these using raw pointers, but then I lose the benefits of
> Rust's compile-time pointer checking. So I tried replacing the raw
> pointers with owned pointers, which more accurately captures the
> meaning of the C interface. But when I do this, the pointers get
> offset by 32 bytes.
>
> [...]

Yeah, there's currently some overhead for owned boxes. From what I
understand, they share the structure of the refcounted managed boxes
with most of the fields nulled out (there's a struct to that effect in
https://github.com/mozilla/rust/blob/incoming/src/libstd/managed.rs#L17
I believe).

I figure this is because managed boxes were there first, and owned boxes
kind of grew out of them, and this is going to change eventually when
someone gets around to it...


> For example, I'd like to replace this:
> 
> struct xmlNode {
>     name:     *i8,
>     ...
> }
> 
> with:
> 
> struct CString;
> 
> struct xmlNode {
>     name:     ~CString,
>     ...
> }
> 
> Then I could (I assume) define safe functions on my CString type (len,
> eq, etc) and not have to worry about memory leaks, etc when using them
> from safe code.
> 
> Is this possible?

I don't believe this is possible in general even accounting for the box
headers somehow because rust isn't promising what malloc/free
implementation it is using for owned pointers.

Maybe someone else has a better idea, but you could wrap the unsafe
pointer into a struct with a safe interface and an impl for the Drop
trait that calls libc's free() for much the same semantics, if a bit
more awkward syntax. I think a type like this ought to be in libextra at
some point, but I don't think there is yet. 

https://github.com/mozilla/rust/blob/incoming/src/libextra/rc.rs does
something similar with refcounting instead of unique ownership
semantics, maybe that's a starting point.


Good luck,
Benjamin Herr

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to