public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@linuxtv.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>,
	lkml <linux-kernel@vger.kernel.org>, akpm <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH] CodingStyle: add typedefs chapter
Date: Tue, 2 May 2006 16:20:50 +0200	[thread overview]
Message-ID: <20060502142050.GC27798@linuxtv.org> (raw)
In-Reply-To: <1146576495.14059.45.camel@pmac.infradead.org>

On Tue, May 02, 2006, David Woodhouse wrote:
> 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."

;-)

Maybe I got it wrong, but my impression so far was that
u8 etc. are preferred for kernel code, and C99 types
are merely tolerated. (Mostly for consistency reasons,
I guess, since most old code uses u8 etc.)

However, personally I don't care either way, I just
want to make sure that code written acording to
Documentation/CodingStyle also meets Linus' expectations.


Johannes

  reply	other threads:[~2006-05-02 14:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-01  0:44 [PATCH] CodingStyle: add typedefs chapter Randy.Dunlap
2006-05-01  7:28 ` Michael Buesch
2006-05-01 15:34   ` Randy.Dunlap
2006-05-01 14:00 ` Jan Engelhardt
2006-05-01 14:19   ` Alexey Dobriyan
2006-05-01 14:46     ` linux-os (Dick Johnson)
2006-05-01 15:01       ` Jiri Slaby
2006-05-01 15:33   ` Artem B. Bityutskiy
2006-05-01 16:58   ` David Woodhouse
2006-05-01 20:20     ` Jan Engelhardt
2006-05-01 20:45       ` Jiri Slaby
2006-05-01 21:01         ` Jan Engelhardt
2006-05-01 21:07           ` David Woodhouse
2006-05-01 21:38             ` Alexey Dobriyan
2006-05-02 10:40               ` Jörn Engel
2006-05-02 13:17             ` Jes Sorensen
2006-05-01 17:06 ` David Woodhouse
2006-05-01 20:48   ` Randy.Dunlap
2006-05-02  0:37   ` Johannes Stezenbach
2006-05-02 13:28     ` David Woodhouse
2006-05-02 14:20       ` Johannes Stezenbach [this message]
2006-05-02 14:31         ` David Woodhouse
2006-05-02 17:11           ` Randy.Dunlap
2006-05-02 18:41             ` Linus Torvalds
2006-05-02 18:50               ` David Woodhouse
2006-05-02 19:07                 ` Linus Torvalds
2006-05-02 19:20                   ` Marcel Siegert
2006-05-02 19:44                     ` Linus Torvalds
2006-05-02 23:22                   ` David Woodhouse
2006-05-03 19:41                     ` Randy.Dunlap
2006-05-03 21:52                       ` David Woodhouse
2006-05-03 22:09                         ` Randy.Dunlap
2006-05-03 22:10                           ` David Woodhouse
2006-05-01 21:23 ` Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060502142050.GC27798@linuxtv.org \
    --to=js@linuxtv.org \
    --cc=akpm@osdl.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox