Show 49 quoted lines
> Le 14 nov. 2025 à 22:09, Ramsay Jones <ramsay@ramsayjones.plus.com> a écrit :
>
>
>
>> On 14/11/2025 10:36 pm, Ezekiel Newren via GitGitGadget wrote:
>> 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]
>
>> +== 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.]
Ben Knoble <ben.knoble@gmail.com>