lkml.org 
[lkml]   [1996]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: uchar


On Sun, 9 Jun 1996, Jon M. Taylor wrote:
>
> In include/linux/types.h, shouldn't
>
> typedef unsigned char unchar;
>
> be
>
> typedef unsigned char uchar; /* no 'n' in uchar */

This doesn't answer your question, but I'd just like to ask all the
people out there _not_ to use the "u[n]char" stuff if at all possible. If
you really want an unsigned char, please type it out.

In the kernel, if you want a "byte" (and you really mean a 8-bit entity),
use "u8" (or __u8 in header files due to namespace pollution). It's
shorter, but more importantly it also makes it very clear that you really
want a 8-bit entity, bot a "char". There is a rather important
distinction.

For "char", you are reasonably safe in assuming it's 8 bits on most
machines, but it gets _really_ interesting when you want 32 bits: do
_not_ use "long" which is definitely wrong, and don't use "int" while is
just sometimes wrong. Use "u32".

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).

People who use BYTE/WORD/LONG (and their "U" versions) have been too
tainted by DOS, and I can only pray that you can see the error of your
ways and slowly recover.

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.

Linus


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