Subject: Re: [PATCH v3 10/10] xdiff: treat xdfile_t.rchg like an enum

From: Phillip Wood <[email-masked]>
Date: Sun, 21 Sep 2025 10:19:35 +0100

On 21/09/2025 01:38, Ezekiel Newren wrote:
> On Sat, Sep 20, 2025 at 6:00 PM Junio C Hamano <[email-masked]> wrote:
>> I am not comfortable with the idea of exposing a set of overly
>> genericly named macros like these, especially when they are *meant*
>> only to be used with xdfile_t.rchg, to those *.c files.  So far,
>> when they include <xdiff-interface.h> (or <ll-merge.h>), they have
>> been rest assured that their namespaces won't be contaminated and
>> they would not risk stepping on others' toes as long as they stay
>> away from inventing their own xdsomething or s_xsomething (neither
>> of which is quite similar to how we name our symbols and types).
> 
> What if I move NO, YES, MAYBE into xprepare.c and refactor `char rchg`
> to `bool changed`? 

That would be good as it avoids the possibility of using MAYBE outside 
of xprepare.c

> The problem with bool is that C needs to include
> stdbool.h to match how Rust defines bool. git-compat-util.h didn't
> include it, then it did, then it didn't because compat/posix.h
> included it instead.

75a044f748f (git-compat-util.h: split out POSIX-emulating bits, 
2025-02-18) moved '#include <stdbool.h>' from "git-compat-util.h" into 
"compat/posix.h" but also added '#include "compat/posix.h"' to 
"git-compat-util.h" so there should be no problem.

Thanks

Phillip

> 
> How do you feel about xdiff.h including compat/posix.h too? If we
> don't use bool on the C side then Rust is going to be littered with
> some_condition != 0 or other_condition == 0 and won't be as clear that
> it's a boolean instead of a numeric type.