Re: [PATCH v4 01/10] doc: define unambiguous type mappings across C and Rust

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Nov 15, 2025, 03:06 UTC
Message-ID: <23b7fd8a-2b50-4da3-bc8a-3727ee99654f@ramsayjones.plus.com>
In-Reply-To: <af732beb6904d8b9b7801ecc2487dabdea05a571.1763159816.git.gitgitgadget@gmail.com>

On 14/11/2025 10:36 pm, Ezekiel Newren via GitGitGadget wrote:

Show 13 quoted lines

> From: Ezekiel Newren <ezekielnewren@gmail.com>
> 
> Document other nuances when crossing the FFI boundary. Other language
> mappings may be added in the future.
> 
> Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com>
> ---
>  Documentation/Makefile                        |   1 +
>  Documentation/technical/meson.build           |   1 +
>  .../technical/unambiguous-types.adoc          | 224 ++++++++++++++++++
>  3 files changed, 226 insertions(+)
>  create mode 100644 Documentation/technical/unambiguous-types.adoc
>

[snip]

Show 13 quoted lines

> +== Character types
> +
> +This is where C and Rust don't have a clean one-to-one mapping.
> +
> +A C `char` and a Rust `u8` share the same bit width, so any C struct containing
> +a `char` will have the same size as the corresponding Rust struct using `u8`.
> +In that sense, such structs are safe to pass over the FFI boundary, because
> +their fields will be laid out identically. However, beyond bit width, C `char`
> +has additional semantics and platform-dependent behavior that can cause
> +problems, as discussed below.
> +
> +C comparison problem: While the sign of `char` is implementation defined, it's
> +also signless (neither signed nor unsigned). When building with

Hmm, this sets my teeth on edge. The C char type is not 'signless' (whatever that is supposed to mean), it's 'sign-ness' is implementation-defined behaviour. This means that it is 'unspecified behavior where each implementation documents how the choice is made'. In particular, it has to document:

  "Which of signed char or unsigned char has the same range, representation, and
   behavior as "plain" char (6.2.5, 6.3.1.1)."

(it is still a distinct type, however). Note that some compilers even allow you to specify which you want for a given compilation! (see gcc options -f[un]signed-char and their inverse 'no' options!)

ATB, Ramsay Jones