On Fri, Apr 15, 2011 at 7:27 AM, Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> wrote: > Those both look sane to me. Those weren't biting me in particular, and > they don't fix the issue I was seeing. But, they do seem necessary to > reduce some of the noise. > > CC'ing the sparse mailing list. We're seeing a couple of cases where > some gcc-isms are either stopping sparse from finding real bugs: > > http://marc.info/?l=linux-mm&m=130282454732689&w=2 I take a look at this problem. The bug can be simplify as the following source: typedef unsigned __attribute__((bitwise)) gfp_t; void foo ( gfp_t flags) { int bit = (__attribute__((force)) int) (flags & (((__attribute__((force)) gfp_t)0x01u)|((__attribute__((force)) gfp_t)0x02u)|((__attribute__((force)) gfp_t)0x04u)|((__attribute__((force)) gfp_t)0x08u))); if (__builtin_constant_p(bit)) ((void)sizeof(char[1 - 2 * !!((( 1 << (0x01u | 0x02u) | 1 << (0x01u | 0x04u) | 1 << (0x04u | 0x02u) | 1 << (0x01u | 0x04u | 0x02u) | 1 << (0x08u | 0x02u | 0x01u) | 1 << (0x08u | 0x04u | 0x01u) | 1 << (0x08u | 0x04u | 0x02u) | 1 << (0x08u | 0x04u | 0x01u | 0x02u) ) >> bit) & 1)])); } Sparse chock on variable length array. It is nothing new. It was useful to warn about the variable length array usage in the kernel, because it might overflow the kernel stack. In this case, it is just a clever trick to issue assert on compile time. We should bite the bullet and just parse the variable length array as expression. We can still issue warning for non constant usage, without the early bail out from sparse. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
