Re: [PATCH 3/3] odb: drop gaps in object info flag values
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 26, 2026, 18:13 UTC
- Message-ID
- <xmqqpl6wi6n4.fsf@gitster.g>
- In-Reply-To
- <add7c86f-9d5e-4136-8c3d-a04df523487b@web.de>
René Scharfe <l.s.r@web.de> writes:
Show 14 quoted lines
>> 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.
Show 10 quoted lines
> 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é