3 ms·
I wonder why so many Rust FFI wrappers don’t use these tools? The most popular C library in the world is probably the standard one. Yet in https://github.com/r
by Const-me 5y ago
I wonder why so many Rust FFI wrappers don’t use these tools?
The most popular C library in the world is probably the standard one. Yet in https://github.com/rust-lang/libc https://github.com/rust-lang/libc I don’t see any glue automatically generated from C headers, everything’s written manually.
Other examples: https://github.com/servo/rust-png/ https://github.com/servo/rust-png/ https://github.com/bozaro/lz4-rs https://github.com/bozaro/lz4-rs
- jcranmer 5y agoThe libc crate's test does actually parse the C header files to generate tests for conformance. There are a few big reasons to consider avoiding parsing the C headers directly: * The C headers might use features in C that are not compatible with the C parser or Rust ABI itself. (C unions used to be a big headache, and bitfields probably still are.). Manually specifying only what you want to import avoids that issue entirely. * As an extended note to the above, many libraries (particularly your system's implementation of libc) are actually not written in any standard C dialect but instead have a lot of compiler-specific things tacked onto it that make it even more difficult to parse and handle correctly than regular C/C++. * Parsing the C headers requires having them installed and being able to find them correctly. When you start dealing with cross-compilation toolchains, this can be a major hassle.
- steveklabnik 5y agoThe first two are older than these tools, not sure about lz4. Not 100% sure why but I would imagine that’s at least a reason.