On 2025-08-29 at 19:42:05, brian m. carlson via GitGitGadget wrote: > +Crates like libc or rustix define types like c_long, but in ways that are not > +safe across platforms. > +From https://docs.rs/rustix/latest/rustix/ffi/type.c_long.html: > + > + This type will always be i32 or i64. Most notably, many Linux-based > + systems assume an i64, but Windows assumes i32. The C standard technically > + only requires that this type be a signed integer that is at least 32 bits > + and at least the size of an int, although in practice, no system would > + have a long that is neither an i32 nor i64. > + > +Also, note that other locations, such as > +https://docs.rs/libc/latest/libc/type.c_long.html, just hardcode c_long as i64 > +even though C may mean i32 on some platforms. > + > +As such, using the c_long type would give us portability issues, and > +perpetuate some of the bugs git has faced across platforms. Avoid using C's > +types (long, unsigned, char, etc.), and switch to unambiguous types (e.g. i32 > +or i64) before trying to make C and Rust interoperate. This makes sense. I agree fixed-size types are better and less brittle. > +Crates like libc and rustix may have also traditionally aided interoperability > +with older versions of Rust (e.g. when worrying about stat[64] system calls), > +but the Rust standard library in newer versions of Rust handle these concerns > +in a platform agnostic way. There may arise cases where we need to consider > +these crates, but for now we omit them. I'm fine with omitting them for now. However, we may very well need them in the future. > +Tools like bindgen and cbindgen create C-styled unsafe Rust code rather than > +idiomatic Rust; where possible, we prefer to switch to idiomatic Rust. Any > +standard C library functions that are needed can be manually wrapped on the > +Rust side. I agree that we want to use idiomatic Rust whenever possible. However, I don't want to define structures and function definitions in both languages and rely on people keeping them in sync, since that's a great way to create brittle, broken code. Very notably, I have seen these kinds of misalignments break only on big-endian architectures, which most of us do not use, so we can really end up causing problems that are very subtle this way. I would prefer we wrote these functions with cbindgen to avoid this. If we define structures only in Rust and never ever use C structures, then we can avoid bindgen. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
