Re: [PATCH 01/15] doc: add a policy for using Rust

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 29, 2025, 20:00 UTC
Message-ID: <aLIG5bLOisbxfn1y@fruit.crustytoothpaste.net>
In-Reply-To: <6d065f550fe871cf010409f7bd2a63438cf52723.1756496539.git.gitgitgadget@gmail.com>

On 2025-08-29 at 19:42:05, brian m. carlson via GitGitGadget wrote:

Show 18 quoted lines

> +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.

Show 5 quoted lines

> +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