Skip to content

Commit c2eb084

Browse files
jwisenikomatsakis
authored andcommitted
Add c_vec library to std.
1 parent 9aa6e57 commit c2eb084

File tree

2 files changed

+100
-1
lines changed

2 files changed

+100
-1
lines changed

src/lib/c_vec.rs

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
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+
}

src/lib/std.rc

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010
export box, char, float, int, str, ptr;
1111
export uint, u8, u32, u64, vec, bool;
1212
export comm, fs, io, net, run, sys, task;
13-
export ctypes, either, option, result, four, tri, util;
13+
export c_vec, ctypes, either, option, result, four, tri, util;
1414
export bitv, deque, fun_treemap, list, map, smallintmap, sort, treemap, ufind;
1515
export rope;
1616
export math, math_f32, math_f64;
@@ -50,6 +50,7 @@ mod task;
5050

5151
// Utility modules
5252

53+
mod c_vec;
5354
mod ctypes;
5455
mod cmath; /* unexported */
5556
mod either;

0 commit comments

Comments
 (0)