From: Ben Knoble Date: Sat, 15 Nov 2025 03:41:36 GMT Subject: Re: [PATCH v4 01/10] doc: define unambiguous type mappings across C and Rust Message-ID: <5A740EE4-D545-4828-8D38-E0E5E9F87A3E@gmail.com> In-Reply-To: <23b7fd8a-2b50-4da3-bc8a-3727ee99654f@ramsayjones.plus.com> > Le 14 nov. 2025 à 22:09, Ramsay Jones a écrit : > >  > >> 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 This was discussed briefly in replies to v2’s 2/10, where Ezekiel said that DEVELOPER=1 warned about sign issues whether char was compared to int or unsigned. [From mobile I cannot reliably paste the message ID or link and preserve a plain-text email, apologies for the oblique reference.]