We’re exploring the development of a crate that would provide alternatives to the extern "C" APIs from this project (e.g., dec), keeping API compatibility and behavior equivalent. The motivation is that some bugs or unsafe assumptions in C libraries can propagate through the FFI boundary, even if Rust wrappers are careful.
We know rewriting mature C libraries is a big effort, so our idea is to provide optional Rust native code that replaces the C library for the selected ABI. We plan to maintain it actively and collaborate with the community, the crate would be fully maintained and actively developed by external contributors, without replacing the original library.
We’d like to understand the community’s stance: would maintainers and users be open to such a Rust-native crate existing and being maintained alongside the current project?
We’re exploring the development of a crate that would provide alternatives to the extern "C" APIs from this project (e.g., dec), keeping API compatibility and behavior equivalent. The motivation is that some bugs or unsafe assumptions in C libraries can propagate through the FFI boundary, even if Rust wrappers are careful.
We know rewriting mature C libraries is a big effort, so our idea is to provide optional Rust native code that replaces the C library for the selected ABI. We plan to maintain it actively and collaborate with the community, the crate would be fully maintained and actively developed by external contributors, without replacing the original library.
We’d like to understand the community’s stance: would maintainers and users be open to such a Rust-native crate existing and being maintained alongside the current project?