4 ms·

I meant generating a safe Rust API for existing C code rather than calling an existing Rust API from C.

• pornel 5y ago
  In that direction it's difficult, because C source code doesn't contain machine-readable information about ownership (who and when can free a pointer), lifetimes, or thread safety. C annotations for aliasing, nullability, and lenghts of arrays (malloced, not VLA) are very basic, and rarely used. Lots of C code isn't even const-correct. Some of these properties could be deduced by a Sufficiently Smart Compiler, but you'd probably need an A.I. that reads the docs.
  • girvo 5y ago
    I’m imagining an interactive tool where it asks those questions of the developer when generating the binding code (c2nim is what I use regularly)
• dangerbird2 5y ago
  bindgen[1] already exists to autogenerate a rust API from c headers. It's inherently unsafe because C code is inherently unsafe. In particular, there is no language constructs like destructors or constructors, so you can't naively create a C-based API that can prevent memory/resource leaks and use after free errors. While C++ does have the same issues as C with unsafe pointer semantics, it does have constructors, destructors, and other features that map almost perfectly with Rust's RAII-based resource management, making it pretty easy to generate a safe(ish) rust interface. In practice, it's pretty easy to create a safe rust API from a C library: use bindgen to create the low-level unsafe API, then create rust wrappers using the ad-hoc creation and descruction library functions to implement RAII. [1] https://rust-lang.github.io/rust-bindgen/ https://rust-lang.github.io/rust-bindgen/