> On Tue, 17 Oct 2017, Mimi Zohar wrote: > > > On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote: > > > > > > On Tue, 17 Oct 2017, Mimi Zohar wrote: > > > > > > > On Tue, 2017-10-17 at 11:50 +0000, Alexander.Steffen@xxxxxxxxxxxx > > > > wrote: > > > > > > > Replace the specification of data structures by pointer > dereferences > > > > > > > as the parameter for the operator "sizeof" to make the > corresponding > > > > > > > size > > > > > > > determination a bit safer according to the Linux coding style > > > > > > > convention. > > > > > > > > > > > > > > > > > > This patch does one style in favor of the other. > > > > > > > > > > I actually prefer that style, so I'd welcome this change :) > > > > > > > > Style changes should be reviewed and documented, like any other > code > > > > change, and added to Documentation/process/coding-style.rst or an > > > > equivalent file. > > > > > > Actually, it has been there for many years: > > > > > > 14) Allocating memory > > > --------------------- > > > ... > > > The preferred form for passing a size of a struct is the following: > > > > > > .. code-block:: c > > > > > > p = kmalloc(sizeof(*p), ...); > > > > > > The alternative form where struct name is spelled out hurts readability > and > > > introduces an opportunity for a bug when the pointer variable type is > changed > > > but the corresponding sizeof that is passed to a memory allocator is not. > > > > True, thanks for the reminder. Is this common in new code? Is there > > a script/ or some other automated way of catching this usage before > > patches are upstreamed? > > > > Just as you're doing here, the patch description should reference this > > in the patch description. > > The comment in the documentation seems have been there since Linux > 2.6.14, > ie 2005. The fact that a lot of code still doesn't use that style, 12 > years later, suggests that actually it is not preferred, or not preferred > by everyone. Perhaps the paragraph in coding style should just be > dropped. Or maybe everyone just copied existing code, which did not follow that pattern, because nobody bothered to fix old code ;-) (This is true at least for tpm_tis_spi, where I was involved in its creation.) Alexander
