Re: [PATCH] Input: cros_ec_keyb - switch from using uint8_t to u8

[Luigi Semenzato <semenzato@chromium.org>]

Thank you, this is useful information, and it would be even more
useful if it made it in Documentation/CodingStyle :-)



On Thu, Jan 2, 2014 at 11:27 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> 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@gmail.com> 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