From: Ramsay Jones Date: Sat, 15 Nov 2025 03:06:06 GMT Subject: Re: [PATCH v4 01/10] doc: define unambiguous type mappings across C and Rust Message-ID: <23b7fd8a-2b50-4da3-bc8a-3727ee99654f@ramsayjones.plus.com> In-Reply-To: On 14/11/2025 10:36 pm, Ezekiel Newren via GitGitGadget wrote: > From: Ezekiel Newren > > Document other nuances when crossing the FFI boundary. Other language > mappings may be added in the future. > > Signed-off-by: Ezekiel Newren > --- > 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] > +== 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