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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]