From: Phillip Wood Date: Sun, 21 Sep 2025 09:19:35 GMT Subject: Re: [PATCH v3 10/10] xdiff: treat xdfile_t.rchg like an enum Message-ID: In-Reply-To: On 21/09/2025 01:38, Ezekiel Newren wrote: > On Sat, Sep 20, 2025 at 6:00 PM Junio C Hamano 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 (or ), 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 ' 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.