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

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Nov 17, 2025, 02:08 UTC
Message-ID: <dd012ab5-d239-49b8-8635-8d22e16c9f1c@ramsayjones.plus.com>
In-Reply-To: <xmqqzf8la20o.fsf@gitster.g>

On 17/11/2025 1:20 am, Junio C Hamano wrote:

Show 8 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Me neither, but I suspect it may mostly use of non-word "signless"
>> that is the issue.
> 
> So, the patch text that claims C's "char" is "signless" still needs
> to be updated, I think.  The problematic paragraph (with a bit of
> rewrapping) reads like this:

Sorry for being AFK for a over a day! :) I didn't think this would generate so much traffic.

Show 5 quoted lines

>     C comparison problem: While the sign of `char` is implementation
>     defined, it's also signless (neither signed nor unsigned). When
>     building with `make DEVELOPER=1` it will complain about a
>     "differ in signedness" when `char` is compared with `uint8_t` or
>     `int8_t`.

Yes, the 'signless' nonsense is what 'triggered' me. ;)

Show 7 quoted lines

> 
> Perhaps
> 
>     The C language leaves the signedness of `char` implementation
>     defined.  Because our developer build enables -Wsign-compare,
>     comparison of a value of `char` type with either signed or
>     unsigned integers will trigger warnings from the compiler.

s/will/may/ - it depends!

>     Avoiding `char` of implementation defined signedness helps us
>     being a bit more explicit.
> 
> or something is sufficient?

Yes, this looks good to me (but then I am not particularly good at word-smithing).

Thanks.

ATB, Ramsay Jones