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

> 
>> 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.]