On Wed, Jul 2, 2014 at 12:43 AM, Phil Carmody <phil@xxxxxxxxxx> wrote: > > Do you care about the precise type of the value? > If you do, then it may be ugly, but it's pretty much obligatory. > And if you don't care about the precise type... Yes, I make a mistake on my macro. But alignment can be precise being unsigned. In a 32 bit system, what if I want to make a 2G align memory? Your signed alignment will force to be a negative value. Which is not precise. >> I don't consider alignment being 4U as wrong by itself. The key question >> is how you use it. > > Absolutely. And doing a ~ and then an up-cast is using it dangerously. > Isn't that what sparse is supposed to be checking for? Well, you still need to get the false positive rate down. Currently then signal to noise ratio is too low. I would not recommend turning it on by default. Did you find some real bug in that 500 error report? Real bug I mean it produce actually bug on the object code it generated. > >> if we introduce: >> >> #define ALIGNMASK(align) (size_t)(~((align) -1)) >> >> And we always use the macro to create mask from alignment value. >> Then there is no need to enforce signedness of the var passed into the >> macro. Hey, it might even read better. > > Put 4U in that, and it still has the flaw of creating a truncated mask. > Put 4 in and it doesn't. Right, I make a mistake on that macro. Good catch. How about #define ALIGNMASK(align) (~((size_t)((align) -1))) Will you be happy if I use 4U with that macro? My point is, with the right macro, you can still use 4U to create alignment. We don't have to fight over 4U vs 4. 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
