From: David Woodhouse <dwmw2@infradead.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Jeff Sipek <jeffpc@optonline.net>, linux-kernel@vger.kernel.org
Subject: Re: Integer types
Date: Sat, 31 Dec 2005 15:47:23 +0000 [thread overview]
Message-ID: <1136044043.3516.155.camel@pmac.infradead.org> (raw)
In-Reply-To: <84144f020512310155r4e99006cn21c5d622b544baa1@mail.gmail.com>
On Sat, 2005-12-31 at 11:55 +0200, Pekka Enberg wrote:
> > * u8, u16, ...
> > * uint8_t, uint16_t, ...
> > * u_int8_t, t_int16_t, ...
>
> From the above list, the first ones. See
> http://article.gmane.org/gmane.linux.kernel/259313. Please note that
> there's also __le32 and __be32 for variables that have fixed byte
> ordering.
As ever, however, be aware that our esteemed leader is fickle.
Especially when he's wrong, as he was on that occasion.
The bit about namespace pollution is a red herring -- that's a good
enough reason for using '__u8', '__u16' etc. in those headers which are
user-visible and which mustn't require standard types, but it's no
excuse for the existence of the 'u8', 'u16' forms in code and headers
which _aren't_ user-visible.
The reason for the existence of the 'uXX' form is because once upon a
time, the kernel was buildable with compilers which predated the C99
standard types. It remains for historical reasons and because some
people (especially Linus) have some kind of emotional attachment to it.
The choice of whether to use 'uXX' or to use the proper standard
'uintXX_t' types is to a large extent a matter of the individual
developer's taste. If you're writing large chunks of your own code, then
do as you see fit; if you're modifying existing code, then use what's
there already.
--
dwmw2
next prev parent reply other threads:[~2005-12-31 15:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-31 8:47 Jeff Sipek
2005-12-31 9:55 ` Pekka Enberg
2005-12-31 15:47 ` David Woodhouse [this message]
2006-01-01 17:09 ` Pekka Enberg
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=1136044043.3516.155.camel@pmac.infradead.org \
--to=dwmw2@infradead.org \
--cc=jeffpc@optonline.net \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
/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
all inboxes | Powered by JetHome®