Re: [PATCH] CodingStyle: add typedefs chapter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2006-05-02 at 02:37 +0200, Johannes Stezenbach wrote:
> IMHO u32 etc. are the well established data types used
> everywhere in kernel source. Your wording suggests that
> the use of C99 types would be better, and while I respect
> your personal opinion, I think it is wrong to put that in the
> kernel CodingStyle document.

Perhaps the word 'gratuitous' should be removed, then, if you object to
being able to infer my opinion.

The point remains that the peculiarity should definitely be documented,
along with an explanation of the reasoning (or lack of such) behind it.

> c.f. http://lkml.org/lkml/2004/12/14/127 

That's about types used for _export_. It's accepted that __uXX types are
necessary in stuff which is visible by userspace. That was point (e).¹

The only bit in that mail which is relevant to my point (d) is the
penultimate (and final) paragraphs. And those are a complete non
sequitur and make just as much sense if you swap over 'u32' and
'uint32_t' and also 'kernel' and 'C language'...

"In other words, uint8_t/uint16_t/uint32_t/uint64_t (and the signed
versions: int8_t and friends) _are_ the standard names in the C
language, and the __u8/__u16/etc versions have always existed alongside
them for things like header files that have namespace issues.

"So forget about that stupid abortion called "u32" already. It buys
you absolutely nothing."

-- 
dwmw2

¹ Actually I had a conversation with Uli the other day in which he
seemed to suggest that proper C99 types _would_ be better, but let's not
go there for now.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux