lkml.org 
[lkml]   [2018]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [ojeda-linux:compiler-attributes-v4 7/13] drivers/firewire/core-card.c:479 bm_work() warn: always true condition '(root_node->max_hops < (16 / 1 + (0))) => (0-15 < 16)'
On Tue, Sep 18, 2018 at 6:11 PM kbuild test robot <lkp@intel.com> wrote:
>
> tree: git://github.com/ojeda/linux compiler-attributes-v4
> head: 7c70bc9e399c67f5d1a84b845d2656f8808e0032
> commit: 431781b83c5e7ae3719498bf1e52ca99bcf6d20b [7/13] Compiler Attributes: remove unneeded sparse (__CHECKER__) tests
>
> smatch warnings:
> drivers/firewire/core-card.c:479 bm_work() warn: always true condition '(root_node->max_hops < (16 / 1 + (0))) => (0-15 < 16)'
> drivers/ide/ide-cd_verbose.c:271 ide_cd_log_error() warn: always true condition '(sense->sense_key < (64 / 4 + (0))) => (0-15 < 16)'

If I understand this correctly, it seems that the condition:

479 root_node->max_hops < ARRAY_SIZE(gap_count_table))

is always true. root_node->max_hops is declared as:

187 u8 max_hops:4; /* Max hops in this sub tree */

in drivers/firewire/core.h, while gap_count_table is declared as:

289 static const char gap_count_table[] = {
290 63, 5, 7, 8, 10, 13, 16, 18, 21, 24, 26, 29, 32, 35, 37,
40
291 };

Since max_hops is a 4b bit vector, its maximal unsigned representable
value is (2^4) - 1 == 15, and 15 is always less that 16, so indeed
this condition is always true.

One issue is that should gap_count_table grow, then this condition may
become always false. Removing the condition might break the then
clause should gap_count_table grow.

Maybe this can be converted to a BUILD_BUG_ON?
--
Thanks,
~Nick Desaulniers

\
 
 \ /
  Last update: 2018-09-19 19:56    [W:0.116 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site