lkml.org 
[lkml]   [1996]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: uchar
Date
From
Thus spake Linus Torvalds:
[snip,snip]
> Some of the kernel device drivers use "uint" or "unsigned long" in
> hardware-specific structures (the layout of a hardware structure in memory,
> for example), and this is just a mail to developers to ask them to consider
> using the u8/u16/u32 types instead (there are also s8/s16/s32 types, but you
> should be _very_ wary about using them: there is very seldom a need for a
> _signed_ quantity that has a certain number of bits).
[snip,snip]
> Oh, and if there isn't any hardware (or protocol, or disk layout) reason
> to use any of u8/u16/u32, please don't. For internal kernel things where
> the exact number of bits doesn't really matter, use "int" or "long" and
> add the full "unsigned" if you want to make it clear that it's an
> unsigned entity.

I _really_ like this, since I've already whined about types in
the kernel in the past (there isn't a platform independent
set used in some code).

PLEASE ADD THIS TO THE CODING SPEC! (if it ain't there already).

How do you et al. feel about using the u8/16/32 and s8/16/32 types
_AND_ typedef'ing them to a more meaningful type?
Example (a really lame one): typedef u16 ioport;
Personally I like this (u8/16/32 describes the size of the quantity,
not what it is being used for), but others may not (so I'm asking).

--
Andrew E. Mileski
mailto:aem@ott.hookup.net http://www.redhat.com/~aem/
Linux Plug-and-Play Project http://www.redhat.com/pnp/

Red Hat Software sponsors these pages - I have no other affilitation
with Red Hat Software, and I have never used any of their products.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.056 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site