4 ms·

Given the implementation of this little thing, I'm mildly curious about how easy it is/will be for a C/C++ project/programmer to use these Rust crates. The oth

Given the implementation of this little thing, I'm mildly curious about how easy it is/will be for a C/C++ project/programmer to use these Rust crates. The other way around is relatively well defined and has been the subject of a lot of attention for several decades. Is the Rust-lib-called-from-C even feasible?

lionkor 3y ago
I feel like Rust was designed to fully replace old languages, and is now facing the same issue as every language before it - C and C++ interop (both ways). Zig nailed it, Rust fucked it up. Time will tell if thats big enough of an issue to warrant some bigger changes to fix it.
- zokier 3y ago
  That is mischaracterization. Rust has been intended to be able to incrementally integrate to C/C++ codebases, of course most significantly integrating Rust/Servo components to Firefox/Gecko. See for example this rsvg presentation[1] and gstreamer blog post[2] for examples of the interop [1] https://viruta.org/docs/fmq-porting-c-to-rust.pdf https://viruta.org/docs/fmq-porting-c-to-rust.pdf [2] https://coaxion.net/blog/2016/05/writing-gstreamer-plugins-and-elements-in-rust/ https://coaxion.net/blog/2016/05/writing-gstreamer-plugins-a...
exDM69 3y ago
Rust can be called from C the same way as C++ can. You need to export unmangled extern "C" symbols. Not quite frictionless but there are helper utilities for this. If the Rust code uses the "StupidAlloc" allocator, it should work as expected. There may be some constructor/destructor code involved with its usual complications. But it would not replace malloc/free in C code nor will it be compatible with C++ allocators for std containers.
conradludgate 3y ago
It has been practical for ages. You define a wrapper function as no_mangle and extern "C", then compile the lib as a staticlib. When compiled, it produces a .a file you can link into your C application
raggi 3y ago
fairly straightforward: #[global_allocator] static GLOBAL: StupidAlloc = StupidAlloc; #[no_mangle] pub unsafe extern "C" fn stupid_malloc(size: usize) -> *mut u8 { let layout = Layout::from_size_align(size, 1).unwrap(); GLOBAL.alloc(layout) } #[no_mangle] pub unsafe extern "C" fn stupid_free(ptr: *mut u8) { let layout = Layout::from_size_align(1, 1).unwrap(); GLOBAL.dealloc(ptr, layout) } then build with --crate-type cdylib, giving you a .so you can link
- lights0123 3y ago
  Although this crate likely enforces a higher alignment (to the page boundary with mmap) regardless of what is requested, you should request a higher alignment because malloc is guaranteed to be aligned to the largest C type, which is usually either 8 or 16 bytes.
  - raggi 3y ago
    fixing the bugs is left as an exercise for the reader
heywhatupboys 3y ago
[flagged]
- OvidiusCicer 3y ago
  The automobile and aero space industry beggs to differ
  - heywhatupboys 3y ago
    they are two separate languages

lionkor 3y ago

I feel like Rust was designed to fully replace old languages, and is now facing the same issue as every language before it - C and C++ interop (both ways). Zig nailed it, Rust fucked it up. Time will tell if thats big enough of an issue to warrant some bigger changes to fix it.

zokier 3y ago
That is mischaracterization. Rust has been intended to be able to incrementally integrate to C/C++ codebases, of course most significantly integrating Rust/Servo components to Firefox/Gecko. See for example this rsvg presentation[1] and gstreamer blog post[2] for examples of the interop [1] https://viruta.org/docs/fmq-porting-c-to-rust.pdf https://viruta.org/docs/fmq-porting-c-to-rust.pdf [2] https://coaxion.net/blog/2016/05/writing-gstreamer-plugins-and-elements-in-rust/ https://coaxion.net/blog/2016/05/writing-gstreamer-plugins-a...

exDM69 3y ago

Rust can be called from C the same way as C++ can. You need to export unmangled extern "C" symbols. Not quite frictionless but there are helper utilities for this. If the Rust code uses the "StupidAlloc" allocator, it should work as expected. There may be some constructor/destructor code involved with its usual complications. But it would not replace malloc/free in C code nor will it be compatible with C++ allocators for std containers.

conradludgate 3y ago

It has been practical for ages. You define a wrapper function as no_mangle and extern "C", then compile the lib as a staticlib. When compiled, it produces a .a file you can link into your C application

raggi 3y ago

fairly straightforward: #[global_allocator] static GLOBAL: StupidAlloc = StupidAlloc; #[no_mangle] pub unsafe extern "C" fn stupid_malloc(size: usize) -> *mut u8 { let layout = Layout::from_size_align(size, 1).unwrap(); GLOBAL.alloc(layout) } #[no_mangle] pub unsafe extern "C" fn stupid_free(ptr: *mut u8) { let layout = Layout::from_size_align(1, 1).unwrap(); GLOBAL.dealloc(ptr, layout) } then build with --crate-type cdylib, giving you a .so you can link

lights0123 3y ago
Although this crate likely enforces a higher alignment (to the page boundary with mmap) regardless of what is requested, you should request a higher alignment because malloc is guaranteed to be aligned to the largest C type, which is usually either 8 or 16 bytes.
- raggi 3y ago
  fixing the bugs is left as an exercise for the reader

heywhatupboys 3y ago

[flagged]

OvidiusCicer 3y ago
The automobile and aero space industry beggs to differ
- heywhatupboys 3y ago
  they are two separate languages