linux-kernel - Re: [PATCH] Input: cros_ec_keyb - switch from using uint8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140102192745.GB2025@core.coreip.homeip.net>
Date:	Thu, 2 Jan 2014 11:27:45 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Doug Anderson <dianders@...omium.org>
Cc:	linux-input@...r.kernel.org, Simon Glass <sjg@...omium.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	Luigi Semenzato <semenzato@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Input: cros_ec_keyb - switch from using uint8_t to u8

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@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/