Re: [PATCH] CodingStyle: add typedefs chapter

[Daniel Barkalow]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/