From: Junio C Hamano Date: Mon, 26 Jan 2026 18:13:51 GMT Subject: Re: [PATCH 3/3] odb: drop gaps in object info flag values Message-ID: In-Reply-To: René Scharfe writes: >> I wonder if this series can be restructured a bit to demonstrate the >> benefit of moving to enum a bit more prominently. For example, even >> at the end of the three patches, odb_read_object_info_extended() >> still takes an "unsigned flags" parameter, but it is meant to take >> this new enum, isn't it? If we do the "#define to enum" conversion >> (without renumbering) first, then "unsigned to enum", would it, with >> appropriate compiler warning flags, already reveal the existing bugs >> that happened to be working OK as potential problems? And with that, >> fixes in 1/3 and 2/3 would demonstrate why #define to enum" is worth >> doing very well. And after all that, we can renumber the enums in a >> separate and final step. > With -Wenum-conversion you can get GCC to report implicit conversions > between different enum types (like in the backfill case), but I don't > see a way to warn about conversions from int (the fsck case). Yes, that is why I suggested "unsigned to enum" change after doing "#define to enum" conversion. If a caller passes an enum with HAS_OBJECT_* to odb_read_object_info_extended() that expects "unsigned flags", it would not be warned, but if the callee expects "enum object_info_flags", passing HAS_OBJECT_* enum to it would be flagged, right? We may need to give the currently-unnamed enum with HAS_OBJECT_* a name first. > https://stackoverflow.com/questions/4669454/how-to-make-gcc-warn-about-passing-wrong-enum-to-a-function > suggests using -Wenum-compare and macros to sneak in a comparison, but > that doesn't seem to catch more than -Wenum-conversion, which doesn't > need any macros. > > https://godbolt.org/z/Whvc7Mf1n > > Perhaps sparse can do that? > > René