On 03/01/2026 at 17:56, Dan Carpenter wrote: > On Sat, Jan 03, 2026 at 12:10:45PM +0100, Vincent Mailhol wrote: >> On 03/01/2026 at 11:02, Dan Carpenter wrote: >>> Thanks Randy, for sending this to me. I'm on the sparse list, but >>> I've been on vacation and haven't caught up with my email. >> >> Welcome back, hope you enjoyed your holidays! >> >>> I can easily silence this in Smatch. >> >> Thanks. I ran this locally, I can confirm that this silences the >> warning. So: >> >> Tested-by: Vincent Mailhol <[email protected]> >> >>> diff --git a/check_unsigned_lt_zero.c b/check_unsigned_lt_zero.c >>> index bfeb3261f91d..ac3e650704ce 100644 >>> --- a/check_unsigned_lt_zero.c >>> +++ b/check_unsigned_lt_zero.c >>> @@ -105,7 +105,8 @@ static bool is_allowed_zero(struct expression *expr) >>> strcmp(macro, "STRTO_H") == 0 || >>> strcmp(macro, "SUB_EXTEND_USTAT") == 0 || >>> strcmp(macro, "TEST_CASTABLE_TO_TYPE_VAR") == 0 || >>> - strcmp(macro, "TEST_ONE_SHIFT") == 0) >>> + strcmp(macro, "TEST_ONE_SHIFT") == 0 || >>> + strcmp(macro, "check_shl_overflow") == 0) >> >> But, for the long term, wouldn't it better to just ignore all the code >> coming from macro extensions instead of maintaining this allow-list? >> > > Of course, that idea occured to me, but so far the allow list is not > very burdensome to maintain.
Indeed, but my concern was more on how people would treat such smatch warnings coming from the kernel test robot. It is very uncommon to have an allow-list hard coded into the static analyzer. Actually, this is the first time I see this. My fear here is that people will just uglify the code rather than sending a patch to extend the allow list in smatch. > I maybe should disable it for all macros unless the --spammy option is used... IMHO, that would be an even better approach. That said, I am happy enough with your previous patch which resolves my issue and which is way better than updating the is_non_negative() and is_negative() comments as I did in my patch! Yours sincerely, Vincent Mailhol
