On Sun, 30 Apr 2006, Randy.Dunlap wrote:
> + (b) Clear integer types, where the abstraction _helps_ avoid confusion
> + whether it is "int" or "long".
> +
> + u8/u16/u32 are perfectly fine typedefs.
> +
> + NOTE! Again - there needs to be a _reason_ for this. If something is
> + "unsigned long", then there's no reason to do
> +
> + typedef long myflags_t;
> +
> + but if there is a clear reason for why it under certain circumstances
> + might be an "unsigned int" and under other configurations might be
> + "unsigned long", then by all means go ahead and use a typedef.
> +
> + (c) when you use sparse to literally create a _new_ type for
> + type-checking.
Is there an official position on "typedef unsigned __bitwise__ myflags_t"?
That is, getting into case (c) with something not particularly useful for
typechecking, just because you want to use a typedef.
I don't remember if the gfp_t thing was only done because it would catch a
very common type of bug, or if it's generally suggested for new code.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
