4 ms·

Does there need to be subtle bugs at the interface if Rust exposes the interface as a C ABI? I think the idea of this article is that you don’t need to underst

Does there need to be subtle bugs at the interface if Rust exposes the interface as a C ABI? I think the idea of this article is that you don’t need to understand two tool chains but instead can focus on the harder task of understanding two languages.

Const-me 5y ago
Yes. Rust does not consume C headers. For every function and data structure of the API surface you gonna need two language projections, C header and Rust source file. For large API surfaces, especially when both sides of the FFI evolve over time, bugs are inevitable. The problem is not specific to Rust. It affects all languages, except C++ and Objective-C which are backward compatible.
- steveklabnik 5y ago
  While Rust itself may not directly, tools like bindgen take in those headers and produce the needed glue. https://cxx.rs/ https://cxx.rs/ is another example of a tool that's used in these sorts of cases. You do not have to write these things, nor keep track of changes, by hand.
  - 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 ago
      The 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 ago
      The 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.
- JoshTriplett 5y ago
  > Rust does not consume C headers. Yet, at least. I hope one day it can, transparently.

Const-me 5y ago

Yes. Rust does not consume C headers. For every function and data structure of the API surface you gonna need two language projections, C header and Rust source file. For large API surfaces, especially when both sides of the FFI evolve over time, bugs are inevitable. The problem is not specific to Rust. It affects all languages, except C++ and Objective-C which are backward compatible.

steveklabnik 5y ago
While Rust itself may not directly, tools like bindgen take in those headers and produce the needed glue. https://cxx.rs/ https://cxx.rs/ is another example of a tool that's used in these sorts of cases. You do not have to write these things, nor keep track of changes, by hand.
- 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 ago
    The 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 ago
    The 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.
JoshTriplett 5y ago
> Rust does not consume C headers. Yet, at least. I hope one day it can, transparently.