|
| 1 | +/* |
| 2 | +Module: c_vec |
| 3 | +
|
| 4 | +Library to interface with chunks of memory allocated in C. |
| 5 | +
|
| 6 | +It is often desirable to safely interface with memory allocated from C, |
| 7 | +encapsulating the unsafety into allocation and destruction time. Indeed, |
| 8 | +allocating memory externally is currently the only way to give Rust shared |
| 9 | +mutable state with C programs that keep their own references; vectors are |
| 10 | +unsuitable because they could be reallocated or moved at any time, and |
| 11 | +importing C memory into a vector takes a one-time snapshot of the memory. |
| 12 | +
|
| 13 | +This module simplifies the usage of such external blocks of memory. Memory |
| 14 | +is encapsulated into an opaque object after creation; the lifecycle of the |
| 15 | +memory can be optionally managed by Rust, if an appropriate destructor |
| 16 | +closure is provided. Safety is ensured by bounds-checking accesses, which |
| 17 | +are marshalled through get and set functions. |
| 18 | +
|
| 19 | +There are three unsafe functions: the two introduction forms, and the |
| 20 | +pointer elimination form. The introduction forms are unsafe for the obvious |
| 21 | +reason (they act on a pointer that cannot be checked inside the method), but |
| 22 | +the elimination form is somewhat more subtle in its unsafety. By using a |
| 23 | +pointer taken from a c_vec::t without keeping a reference to the c_vec::t |
| 24 | +itself around, the c_vec could be garbage collected, and the memory within |
| 25 | +could be destroyed. There are legitimate uses for the pointer elimination |
| 26 | +form -- for instance, to pass memory back into C -- but great care must be |
| 27 | +taken to ensure that a reference to the c_vec::t is still held if needed. |
| 28 | +
|
| 29 | + */ |
| 30 | + |
| 31 | +export t; |
| 32 | +export create, create_with_dtor; |
| 33 | +export get, set; |
| 34 | +export size; |
| 35 | +export ptr; |
| 36 | + |
| 37 | +/* |
| 38 | + Type: t |
| 39 | +
|
| 40 | + The type representing a native chunk of memory. Wrapped in a tag for |
| 41 | + opacity; FIXME #818 when it is possible to have truly opaque types, this |
| 42 | + should be revisited. |
| 43 | + */ |
| 44 | + |
| 45 | +tag t<T> { |
| 46 | + t({ base: *T, size: uint, rsrc: @dtor_res}); |
| 47 | +} |
| 48 | + |
| 49 | +resource dtor_res(dtor: option::t<fn@()>) { |
| 50 | + alt dtor { |
| 51 | + option::none. { } |
| 52 | + option::some(f) { f(); } |
| 53 | + } |
| 54 | +} |
| 55 | + |
| 56 | +/* |
| 57 | + Section: Introduction forms |
| 58 | + */ |
| 59 | + |
| 60 | +unsafe fn create<T>(base: *T, size: uint) -> t<T> { |
| 61 | + ret t({base: base, |
| 62 | + size: size, |
| 63 | + rsrc: @dtor_res(option::none) |
| 64 | + }); |
| 65 | +} |
| 66 | + |
| 67 | +unsafe fn create_with_dtor<T>(base: *T, size: uint, dtor: fn@()) -> t<T> { |
| 68 | + ret t({base: base, |
| 69 | + size: size, |
| 70 | + rsrc: @dtor_res(option::some(dtor)) |
| 71 | + }); |
| 72 | +} |
| 73 | + |
| 74 | +/* |
| 75 | + Section: Operations |
| 76 | + */ |
| 77 | + |
| 78 | +fn get<copy T>(t: t<T>, ofs: uint) -> T { |
| 79 | + assert ofs < (*t).size; |
| 80 | + ret unsafe { *ptr::offset((*t).base, ofs) }; |
| 81 | +} |
| 82 | + |
| 83 | +fn set<copy T>(t: t<T>, ofs: uint, v: T) { |
| 84 | + assert ofs < (*t).size; |
| 85 | + unsafe { *(ptr::offset((*t).base, ofs) as *mutable T) = v }; |
| 86 | +} |
| 87 | + |
| 88 | +/* |
| 89 | + Section: Elimination forms |
| 90 | + */ |
| 91 | + |
| 92 | +fn size<T>(t: t<T>) -> uint { |
| 93 | + ret (*t).size; |
| 94 | +} |
| 95 | + |
| 96 | +unsafe fn ptr<T>(t: t<T>) -> *T { |
| 97 | + ret (*t).base; |
| 98 | +} |
0 commit comments