https://lgtm.com/projects/g/TrenchBoot/landing-zone/snapshot/164a7bcef098d7352fa3731e5392a2109491a9f0/files/dev.c?sort=name&dir=ASC&mode=heatmap#x203928dc5733003b:1
Paraphrasing, it has found:
u32 dev_caps = ...;
for (u8 i = 0; i < DEV_CAP_MAPS(dev_cap); i++)
...
The statement about different types is technically true (as it only discusses types), but unhelpful.
The macro DEV_CAP_MAPS() is:
#define DEV_CAP_MAPS(c) ((c & 0xFF0000) >> 16)
so while the type is larger than u8, its range is restricted to that of u8, so no overflow can occur as a consequence.
There are plenty of ways to rewrite DEV_CAP_MAPS() so LGTM would be happy with it, most obviously (u8)(c >> 16), but the above expression is very common in embedded C, so it would be more helpful to adjust the check to take into account any range restrictions, rather than just considering type.
https://lgtm.com/projects/g/TrenchBoot/landing-zone/snapshot/164a7bcef098d7352fa3731e5392a2109491a9f0/files/dev.c?sort=name&dir=ASC&mode=heatmap#x203928dc5733003b:1
Paraphrasing, it has found:
The statement about different types is technically true (as it only discusses types), but unhelpful.
The macro
DEV_CAP_MAPS()is:so while the type is larger than u8, its range is restricted to that of u8, so no overflow can occur as a consequence.
There are plenty of ways to rewrite
DEV_CAP_MAPS()so LGTM would be happy with it, most obviously(u8)(c >> 16), but the above expression is very common in embedded C, so it would be more helpful to adjust the check to take into account any range restrictions, rather than just considering type.