CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

There are valid reasons for

malloc(sizeof(struct S))

form:

* struct S acts as an anchor for ctags quickly reminding which type is in focus

* argument re changing name prevents bugs is semi bogus:
such changes are rare,
"void *" cast gives both forms equal opportunity to be screwed up

* proper way to fix those rare misallocation bugs (which indeed happened) is type safe allocation macros (see tmalloc from Samba).

However amount of disruption will be so high so it may never be done.

* ratio of allocation styles is ~6400:12000 which is about 1:2 so the amount of churn to maintain this rule is pretty high in theory.

The winning move is to not play and not encourage people send trivial stuff.

Signed-off-by Alexey Dobriyan <[email protected]>

---

 Documentation/process/coding-style.rst |   10 ----------
 1 file changed, 10 deletions(-)

Documentation/process/coding-style.rst +0 -3

@@ -808,16 +808,6 @@ kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
 vzalloc().  Please refer to the API documentation for further information
 about them.
 
-The preferred form for passing a size of a struct is the following:
-
-.. code-block:: c

Quoted 35 lines · Alexey Dobriyan

There are valid reasons for

malloc(sizeof(struct S))

form:

* struct S acts as an anchor for ctags quickly reminding which type is in focus

* argument re changing name prevents bugs is semi bogus:
such changes are rare,
"void *" cast gives both forms equal opportunity to be screwed up

* proper way to fix those rare misallocation bugs (which indeed happened) is type safe allocation macros (see tmalloc from Samba).

However amount of disruption will be so high so it may never be done.

* ratio of allocation styles is ~6400:12000 which is about 1:2 so the amount of churn to maintain this rule is pretty high in theory.

The winning move is to not play and not encourage people send trivial stuff.

Signed-off-by Alexey Dobriyan <[email protected]>

---

 Documentation/process/coding-style.rst |   10 ----------
 1 file changed, 10 deletions(-)

Documentation/process/coding-style.rst +0 -0

@@ -808,16 +808,6 @@ kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
 vzalloc().  Please refer to the API documentation for further information
 about them.
 

Documentation/process/coding-style.rst kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and · line 813

Quoted 13 lines

Documentation/process/coding-style.rst +0 -10

-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.
-
 Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.

Thanks. I agree with this deletion.

Quoted 35 lines · Alexey Dobriyan

There are valid reasons for

malloc(sizeof(struct S))

form:

* struct S acts as an anchor for ctags quickly reminding which type is in focus

* argument re changing name prevents bugs is semi bogus:
such changes are rare,
"void *" cast gives both forms equal opportunity to be screwed up

* proper way to fix those rare misallocation bugs (which indeed happened) is type safe allocation macros (see tmalloc from Samba).

However amount of disruption will be so high so it may never be done.

* ratio of allocation styles is ~6400:12000 which is about 1:2 so the amount of churn to maintain this rule is pretty high in theory.

The winning move is to not play and not encourage people send trivial stuff.

Signed-off-by Alexey Dobriyan <[email protected]>

---

 Documentation/process/coding-style.rst |   10 ----------
 1 file changed, 10 deletions(-)

Documentation/process/coding-style.rst +0 -0

@@ -808,16 +808,6 @@ kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
 vzalloc().  Please refer to the API documentation for further information
 about them.
 

Documentation/process/coding-style.rst kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and · line 813

Quoted 13 lines

Documentation/process/coding-style.rst +0 -10

-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.
-
 Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.

Thanks. I agree with this deletion.

Quoted 3 lines · On Mon, 22 May 2017 14:43:18 -0700 Joe Perches <[email protected]> wrote:

Quoted 2 lines · Alexey Dobriyan

* ratio of allocation styles is ~6400:12000 which is about 1:2 so the amount of churn to maintain this rule is pretty high in theory.

Quoted 4 lines

Quoted 4 lines

Documentation/process/coding-style.rst +0 -4

-The preferred form for passing a size of a struct is the following:
-
-.. code-block:: c
-

Quoted 8 lines

Documentation/process/coding-style.rst kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and · line 820

Quoted 6 lines

Documentation/process/coding-style.rst +0 -6

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

Thanks. I agree with this deletion.

I don't. Every damn time I see a p = kmalloc(sizeof struct foo) I have to hunt around to check the type of p. And I review a lot of code!

Quoted 17 lines · On Mon, 22 May 2017 14:43:18 -0700 Joe Perches <[email protected]> wrote:

Documentation/process/coding-style.rst kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and · line 813

Quoted 13 lines · Alexey Dobriyan

Documentation/process/coding-style.rst +0 -10

-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.
-
 Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.

Thanks. I agree with this deletion.

I don't. Every damn time I see a p = kmalloc(sizeof struct foo) I have to hunt around to check the type of p.

Proper fix is to introduce typed allocation macros with the following signatures:

T* lmalloc(T, gfp);

    struct foo *x;
    x = lmalloc(struct foo, GFP_KERNEL);

Quoted 4 lines · Alexey Dobriyan

Proper fix is to introduce typed allocation macros with the following signatures:

T* lmalloc(T, gfp);

Quoted 2 lines

    struct foo *x;
    x = lmalloc(struct foo, GFP_KERNEL);

Then code would be written

	x = lmalloc(typeof(*x), GFP_KERNEL);

Quoted 5 lines · Joe Perches

Quoted 4 lines · Alexey Dobriyan

Proper fix is to introduce typed allocation macros with the following signatures:

T* lmalloc(T, gfp);

Ack (FWIW).

[...]

Quoted 6 lines

Quoted 2 lines

    struct foo *x;
    x = lmalloc(struct foo, GFP_KERNEL);

Then code would be written

	x = lmalloc(typeof(*x), GFP_KERNEL);

At least it is correct and changes automagically if x changes the type which

	struct bar *x;
	x = kmalloc(sizeof(struct foo), GFP_KERNEL);

doesn't do and the compiler doesn't complain.

And the typeof() version could be written that way today but I can't remember seeing it (in the kernel and elsewhere).