On Fri, Aug 13, 2021 at 09:57:14AM +1000, Dave Chinner wrote:
> FWIW, I just assumed it was a current TOT being checked because
> c809d7e948a1 was introduced in 5.14-rc1 and that's the commit smatch
> is, IMO, incorrectly blaming. Commit 777eb1fa857e ("xfs: remove
> xfs_dqrele_all_inodes") which is the one in for-next that removed
> the XFS_ICWALK_DQRELE definition from the enum and so, under C90,
> gcc will turn the enum from from signed to unsigned. But we still
> build the kernel under C89, so it's not clear to me that the smatch
> assertion is correct...
No, it's still unsigned with -std=gnu89.
#include <stdio.h>
enum num { ONE, TWO };
int main(void)
{
enum num x;
x = -1;
if (x < 0)
printf("signed\n");
else
printf("unsigned\n");
return 0;
}
$ gcc -std=gnu89 test.c
$ ./a.out
unsigned
$
>
> Perhaps there might be some improvements that can be made to smatch
> to handle this better. Knowing what tree was being checked would
> also help us here.
Yep. My bad.
regards,
dan carpenter
