Skip to contentSkip to conversation

staging: unisys: Remove allocation from declaration line

PATCH Superseded Quentin Lambert 4 participants 5 messages Feb 10, 2015 – Feb 12, 2015

Subsystems (2)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 staging: unisys: Remove allocation from declaration line

This patch removes allocation from declaration line because people are known to gloss over declarations.

---
 drivers/staging/unisys/visorchipset/visorchipset_main.c | 6 +++---
 drivers/staging/unisys/visorutil/charqueue.c            | 3 ++-
 drivers/staging/unisys/visorutil/memregion_direct.c     | 5 +++--
 3 files changed, 8 insertions(+), 6 deletions(-)
drivers/staging/unisys/visorchipset/visorchipset_main.c +3 -3
index 82e259d..a6c6bb7 100644
@@ -1604,9 +1604,9 @@ parahotplug_next_expiration(void)
 static struct parahotplug_request *
 parahotplug_request_create(struct controlvm_message *msg)
 {
-	struct parahotplug_request *req =
-	    kmalloc(sizeof(struct parahotplug_request),
-		    GFP_KERNEL|__GFP_NORETRY);
+	struct parahotplug_request *req;
+
+	req = kmalloc(sizeof(struct parahotplug_request), GFP_KERNEL|__GFP_NORETRY);
 	if (req == NULL)
 		return NULL;
 
drivers/staging/unisys/visorutil/charqueue.c +2 -1
index ac7acb7..e2ee5ee 100644
@@ -36,8 +36,9 @@ struct charqueue {
 struct charqueue *visor_charqueue_create(ulong nslots)
 {
 	int alloc_size = sizeof(struct charqueue) + nslots + 1;
-	struct charqueue *cq = kmalloc(alloc_size, GFP_KERNEL|__GFP_NORETRY);
+	struct charqueue *cq;
 
+	cq = kmalloc(alloc_size, GFP_KERNEL|__GFP_NORETRY);
 	if (cq == NULL) {
 		ERRDRV("visor_charqueue_create allocation failed (alloc_size=%d)",
 		       alloc_size);
drivers/staging/unisys/visorutil/memregion_direct.c +3 -2
index 33522cc..f4ecac0 100644
@@ -41,8 +41,9 @@ struct memregion *
 visor_memregion_create(HOSTADDRESS physaddr, ulong nbytes)
 {
 	struct memregion *rc = NULL;
-	struct memregion *memregion = kzalloc(sizeof(*memregion),
-					      GFP_KERNEL | __GFP_NORETRY);
+	struct memregion *memregion;
+
+	memregion = kzalloc(sizeof(*memregion), GFP_KERNEL | __GFP_NORETRY);
 	if (memregion == NULL) {
 		ERRDRV("visor_memregion_create allocation failed");
 		return NULL;
Signature · 1 line
1.9.1
#1 lore raw
Quoted 15 lines · Quentin Lambert

This patch removes allocation from declaration line because people are known to gloss over declarations.

---
 drivers/staging/unisys/visorchipset/visorchipset_main.c | 6 +++---
 drivers/staging/unisys/visorutil/charqueue.c            | 3 ++-
 drivers/staging/unisys/visorutil/memregion_direct.c     | 5 +++--
 3 files changed, 8 insertions(+), 6 deletions(-)
drivers/staging/unisys/visorchipset/visorchipset_main.c +0 -0
index 82e259d..a6c6bb7 100644

drivers/staging/unisys/visorchipset/visorchipset_main.c parahotplug_next_expiration(void) · line 1609

Quoted 9 lines
drivers/staging/unisys/visorchipset/visorchipset_main.c +3 -3
@@ -1604,9 +1604,9 @@ parahotplug_next_expiration(void)
 static struct parahotplug_request *
 parahotplug_request_create(struct controlvm_message *msg)
 {
-	struct parahotplug_request *req =
-	    kmalloc(sizeof(struct parahotplug_request),
-		    GFP_KERNEL|__GFP_NORETRY);
+	struct parahotplug_request *req;
+
+	req = kmalloc(sizeof(struct parahotplug_request), GFP_KERNEL|__GFP_NORETRY);

if you make it as:

	req = kmalloc(sizeof(*req), GFP_KERNEL|__GFP_NORETRY);

then this will not give you checkpatch warning of line over 80 char.

regards
sudip

Quoted 2 lines
drivers/staging/unisys/visorchipset/visorchipset_main.c +0 -0
 	if (req == NULL)
 		return NULL;

<snip>

Quoted 9 lines

return NULL;

Signature · 7 lines
1.9.1

--
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/
#2 lore raw
In reply to Quentin Lambert
Quoted 2 lines · Quentin Lambert

This patch removes allocation from declaration line because people are known to gloss over declarations.

Again, who are these lazy people, and why are they reading kernel code?

Please, it's ok to allocate things in the declaration line, don't make these kinds of changes.

greg k-h

#3 lore raw
Quoted 6 lines · Greg Kroah-Hartman
Quoted 2 lines · Quentin Lambert

This patch removes allocation from declaration line because people are known to gloss over declarations.

Again, who are these lazy people, and why are they reading kernel code?

From my work with smatch:
1) Probably 70-80% of inconsistent NULL checking is when done in the initializer. I'm sending a patch for one of these today.
2) If there is an allocation in the initializer then it's more likely that the NULL check will be missing.
Initializers are a blind spot that people do not read. It's not just one maintainer, it's consistent across the board.

Also if you put an allocation in the initializer then it almost always has to be mangled to fit in 80 characters and it looks ugly. But after these patches then all the allocations fit naturally.

Plus you have to have that blank line to separate the initialization paragraph from the paragraph with the check for allocation failure.

Really, it is fairly uncommon to put an allocation in the initalizer.

regards,
dan carpenter

#4 lore raw
Quoted 18 lines · Dan Carpenter
Quoted 5 lines · Greg Kroah-Hartman
Quoted 2 lines · Quentin Lambert

This patch removes allocation from declaration line because people are known to gloss over declarations.

Again, who are these lazy people, and why are they reading kernel code?

From my work with smatch:
1) Probably 70-80% of inconsistent NULL checking is when done in the initializer. I'm sending a patch for one of these today.
2) If there is an allocation in the initializer then it's more likely that the NULL check will be missing.
Initializers are a blind spot that people do not read. It's not just one maintainer, it's consistent across the board.

Also if you put an allocation in the initializer then it almost always has to be mangled to fit in 80 characters and it looks ugly. But after these patches then all the allocations fit naturally.

Quoted 7 lines

Plus you have to have that blank line to separate the initialization paragraph from the paragraph with the check for allocation failure.

Really, it is fairly uncommon to put an allocation in the initalizer.

regards,
dan carpenter

In the case this patch wasn't accepted what should I do with this one: https://lkml.org/lkml/2015/2/10/182 ?

Do you want me to submit a non-dependent version?

regards,
Quentin