Used PTR_RET function instead of IS_ERR and PTR_ERR.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu <[email protected]>
---
drivers/virtio/virtio_mmio.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 1ba0d68..d1e664f 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -567,10 +567,7 @@ static int vm_cmdline_set(const char *device,
pdev = platform_device_register_resndata(&vm_cmdline_parent,
"virtio-mmio", vm_cmdline_id++,
resources, ARRAY_SIZE(resources), NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- return 0;
+ return PTR_RET(pdev);
}
static int vm_cmdline_get_device(struct device *dev, void *data)
--
1.7.9.5
Alexandru Gheorghiu <[email protected]> writes:
> Used PTR_RET function instead of IS_ERR and PTR_ERR.
> Patch found using coccinelle.
WTF is PTR_RET? PTR_RET doesn't return anything. Why is it called
that? It doesn't even make sense.
ZERO_OR_PTR_ERR() maybe.
But what problem are we solving? Insufficient churn in the tree? Code
being too readable? This isn't some hard-to-get right corner case, or a
missed optimization.
Andrew, what am I missing here?
Grumpy,
Rusty.
> Signed-off-by: Alexandru Gheorghiu <[email protected]>
> ---
> drivers/virtio/virtio_mmio.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 1ba0d68..d1e664f 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -567,10 +567,7 @@ static int vm_cmdline_set(const char *device,
> pdev = platform_device_register_resndata(&vm_cmdline_parent,
> "virtio-mmio", vm_cmdline_id++,
> resources, ARRAY_SIZE(resources), NULL, 0);
> - if (IS_ERR(pdev))
> - return PTR_ERR(pdev);
> -
> - return 0;
> + return PTR_RET(pdev);
> }
>
> static int vm_cmdline_get_device(struct device *dev, void *data)
> --
> 1.7.9.5
On Tue, 26 Mar 2013 13:57:09 +1030 Rusty Russell <[email protected]> wrote:
> Alexandru Gheorghiu <[email protected]> writes:
>
> > Used PTR_RET function instead of IS_ERR and PTR_ERR.
> > Patch found using coccinelle.
>
> WTF is PTR_RET? PTR_RET doesn't return anything. Why is it called
> that? It doesn't even make sense.
>
> ZERO_OR_PTR_ERR() maybe.
>
> But what problem are we solving? Insufficient churn in the tree? Code
> being too readable? This isn't some hard-to-get right corner case, or a
> missed optimization.
>
> Andrew, what am I missing here?
It seemed like a good idea at the time. Merged it two years ago and
have since been keenly awaiting an opportunity to use it.
It seems that people _have_ been using it, but mainly netfilter people
and we know they're all crazy ;)
Andru Gheorghiu <[email protected]> writes:
> PTR_RET does return. It's perfectly equivalent to using IS_ERR and the
> returning PTR_ERR. The implementation is here [1].
Um, I read the implementation, thanks.
> The reason for using it is this: if you have a function that does
> something why not call it instead of reproducing it's behavior by
> explicitly writing what it does.
Because clarity matters, and this function makes callers less clear.
It's the most breathtakingly bad name since BUILD_BUG_ON_ZERO().
Why not change PTR_ERR to return 0 if !IS_ERR()? Noone breaks, gcc
probably produces the same code, and noone needs to learn your weird
new kernel meme.
In fact, as gcc will produce the same code for "if (PTR_ERR(p))" as it
does for "if (IS_ERR(p))", you get to be one of the very, very few
people who have ever *reduced* the complexity of a kernel interface.
Cheers,
Rusty.