| commit | bd97ff4e1a521d74473c70260a92042cd5b1a5c6 | |
| author | Dan Carpenter <dan.carpenter@oracle.com> | |
| Wed, 16 Dec 2020 13:50:23 +0000 (16 16:50 +0300) | ||
| committer | Dan Carpenter <dan.carpenter@oracle.com> | |
| Wed, 16 Dec 2020 13:50:23 +0000 (16 16:50 +0300) | ||
| tree | 27c1e7d3469ef283f0bd8c9f660968b482ab272d | treesnapshot (tar.gz zip) |
| parent | cae9c11f83bb43601899f46aef1a1d070f87ee5c | commitdiff |
math: INT_MAX is never a hard max
There are a lot of checks in the kernel for:
if (foo > INT_MAX)
return -EINVAL;
But those checks are just to ensure that "foo" doesn't overflow the type,
it's not because we think that the array has INT_MAX members so it's not
a hard max.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
There are a lot of checks in the kernel for:
if (foo > INT_MAX)
return -EINVAL;
But those checks are just to ensure that "foo" doesn't overflow the type,
it's not because we think that the array has INT_MAX members so it's not
a hard max.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
| smatch_math.c | diffblobblamehistory |