Messages in this thread |  | | Date | Mon, 10 Jun 1996 06:55:17 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: 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
|  |