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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 17, 2025, 01:20 UTC
Message-ID: <xmqqzf8la20o.fsf@gitster.g>
In-Reply-To: <xmqqpl9jfdso.fsf@gitster.g>

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:

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

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.
    Avoiding `char` of implementation defined signedness helps us
    being a bit more explicit.

or something is sufficient?