On Tue, Mar 06, 2018 at 12:43:26PM -0600, Christopher Lameter wrote: > On Mon, 5 Mar 2018, Alexey Dobriyan wrote: > > > ->reserved is either 0 or sizeof(struct rcu_head), can't be negative. > > Thus it should be size_t? ;-) :-) Christoph, using "unsigned int" should be default for kernel really. As was noted earlier it doesn't matter for constants as x86_64 clears upper half of a register. But it matters for sizes which aren't known at compile time. I've looked at a lot of places where size_t is used. There is a certain degree of "type correctness" when people try to keep type as much as possible. It works until first multiplication. int n; size_t len = sizeof(struct foo0) + n * sizeof(struct foo); Most likely MOVSX or CDQE will be generated which is not the case if everything is "unsigned int". Generally, on x86_64, uint32_t > uint64_t > uint16_t uint8_t > uint64_t adds REX prefix. uint16_t additionally adds 66 prefix uint8_t doesn't add anything but it is suboptimal on embedded archs which emit "& 0xff" and thus should be used only for trimming memory usage. Additionally, unsigned int > int as it is easy for compiler to lose track of value range and generate size extensions. There is only one exception, namely, when pointers are mixed with integers: int n; void *p = p0 + n; Quite often, gcc generates bigger code when types are made unsigned. I don't quite understand how it thinks, but overall code will be smaller if every signed type is made into unsigned.
