On Thu, Jan 02, 2014 at 08:12:09AM -0800, Doug Anderson wrote: > Dmitry, > > On Tue, Dec 31, 2013 at 11:34 AM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > u8 is proper in-kernel type for unsigned byte data. > > I won't say that I keep up with all the latest trends here, but this > surprised me so I did some research. My findings don't agree with > your statement. Perhaps there are different standards that are used > for the input subsystem? > > Specifically looking at > <https://www.kernel.org/doc/Documentation/CodingStyle>, I see: > > Therefore, the Linux-specific 'u8/u16/u32/u64' types and their > signed equivalents which are identical to standard types are > permitted -- although they are not mandatory in new code of your > own. > > When editing existing code which already uses one or the other set > of types, you should conform to the existing choices in that code. > > That makes it sound like the author of that document would prefer > uint8_t but will accept u8. It also seems like if code is consistent > about using a given type (as this code is) that it shouldn't be > changed. > > I'm always happy to be enlightened, though! I prefer uXX in kernel because it matches __uXX that we publish in UAPI. Also here is Linus's response form the discussion that introduced that particular wording in CodingStyle [1]: "The problem with uint32_t is that it's ugly, it used to be unportable, and you can't use it in header files _anyway_. In other words, there's no _point_ to the "standard type". I really object to this whole thing. The fact is, "u8" and friends _are_ the standard types as far as the kernel is concerned. Claiming that they aren't is just silly. It's the "uint32_t" kind of thing that isn't standard within the kernel. You can't use that thing in public header files anyway due to name scoping rules, so they have basically no redeeming features." Thanks. -- Dmitry [1] http://marc.info/?l=linux-kernel&m=114659539715468&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
