Dmitry,
On Tue, Dec 31, 2013 at 11:34 AM, Dmitry Torokhov
<[email protected]> 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!
-Doug
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
> <[email protected]> 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
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
<[email protected]> 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
>> <[email protected]> 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