On Thu, May 23, 2019 at 10:36 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > Of course, you probably want the usual "at least use 'int'" semantics, > > in which case the "type" should be "(x)+0": > > > > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y) > > > > and the 8-bit and 16-bit cases will never be used. > > I'm curious to what the advantage of that is? Let's say that you have a structure with a 'unsigned char' member, because the value range is 0-255. What happens if you do x = round_up(p->member, 4); and the value is 255? Now, if you stay in 'unsigned char' the end result is 0. If you follow the usual C integer promotion rules ("all arithmetic promotes to at least 'int'"), you get 256. Most people probably expect 256, and that implies that even if you pass an 'unsigned char' to an arithmetic function like this, you expect any math to be done in 'int'. Doing the "(x)+0" forces that, because the "+0" changes the type of the expression from "unsigned char" to "int" due to C integer promotion. Yes. The C integer type rules are subtle and sometimes surprising. One of the things I've wanted is to have some way to limit silent promotion (and silent truncation!), and cause warnings. 'sparse' does some of that with some special-case types (ie __bitwise), but it's pretty limited. Linus _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel