* Integer types
@ 2005-12-31 8:47 Jeff Sipek
2005-12-31 9:55 ` Pekka Enberg
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Sipek @ 2005-12-31 8:47 UTC (permalink / raw)
To: linux-kernel
What's the prefered integer type for kernel code?
* u8, u16, ...
* uint8_t, uint16_t, ...
* u_int8_t, t_int16_t, ...
Thanks,
Josef "Jeff" Sipek.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Integer types
2005-12-31 8:47 Integer types Jeff Sipek
@ 2005-12-31 9:55 ` Pekka Enberg
2005-12-31 15:47 ` David Woodhouse
0 siblings, 1 reply; 4+ messages in thread
From: Pekka Enberg @ 2005-12-31 9:55 UTC (permalink / raw)
To: Jeff Sipek; +Cc: linux-kernel
On 12/31/05, Jeff Sipek <jeffpc@optonline.net> wrote:
> What's the prefered integer type for kernel code?
>
> * 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.
Pekka
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Integer types
2005-12-31 9:55 ` Pekka Enberg
@ 2005-12-31 15:47 ` David Woodhouse
2006-01-01 17:09 ` Pekka Enberg
0 siblings, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2005-12-31 15:47 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Jeff Sipek, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Integer types
2005-12-31 15:47 ` David Woodhouse
@ 2006-01-01 17:09 ` Pekka Enberg
0 siblings, 0 replies; 4+ messages in thread
From: Pekka Enberg @ 2006-01-01 17:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: Jeff Sipek, linux-kernel
Hi,
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.
On 12/31/05, David Woodhouse <dwmw2@infradead.org> wrote:
> As ever, however, be aware that our esteemed leader is fickle.
> Especially when he's wrong, as he was on that occasion.
Maybe so but some maintainers do require them. So as for the original
question, I would still recommend the u8 ones as they are most likely
merged as is.
Pekka
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-01-01 17:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-31 8:47 Integer types Jeff Sipek
2005-12-31 9:55 ` Pekka Enberg
2005-12-31 15:47 ` David Woodhouse
2006-01-01 17:09 ` Pekka Enberg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.