Preceding a method call with (void)

Preceding a method call with (void)

[Kevin Wilson]

Hi all,

I intend to send a patch to the kernel, and my question is about
preceding a method with (void).

In several OpenSource UserSpace projects, I encountered usage of
preceding a method invocation with (void).

For example:

(void) myFunc(param1);

I did not encounter such cases in the kernel code that I read, thus far.

On the other hand, I did not saw in the kernel coding style doc
anything which prohibits such usage.

If I remember, using (void) before the method name is a way to tell
explicitly that this method does not return any value,
but I am not sure as for the exact reasons it is used (in userspace).

My question is:
Will sending a patch to the kernel with code with (void) preceding
method calls make sense ?
or should I avoid it in  the first place (again, I did not saw such a
pattern in the kernel)

Regards,
Kevin

Preceding a method call with (void)

[Greg KH]

On Thu, Sep 10, 2015 at 07:52:49AM +0300, Kevin Wilson wrote:
> Hi all,
> 
> I intend to send a patch to the kernel, and my question is about
> preceding a method with (void).

Don't :)

> My question is:
> Will sending a patch to the kernel with code with (void) preceding
> method calls make sense ?

Nope.

> or should I avoid it in  the first place (again, I did not saw such a
> pattern in the kernel)

Avoid it please.

Just curious, what code do you want to change to add a (void) to?

thanks,

greg k-h

Preceding a method call with (void)

[Valdis.Kletnieks at vt.edu]

On Thu, 10 Sep 2015 07:52:49 +0300, Kevin Wilson said:

> (void) myFunc(param1);
>
> I did not encounter such cases in the kernel code that I read, thus far.
>
> On the other hand, I did not saw in the kernel coding style doc
> anything which prohibits such usage.
>
> If I remember, using (void) before the method name is a way to tell
> explicitly that this method does not return any value,
> but I am not sure as for the exact reasons it is used (in userspace).

Well, if the function actually returns nothing, in kernel code we usually
declare it as:

void myFunc( int param1)
{
/* yadda yadda yadda *.
}

Given that, what reason is there for casting the return value with (void)?

(And if the function is actually   'int myFunc ( int param1) {...}',
why are you calling it and then ignoring the return value?  That's a clue
that you're abusing the API...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150910/fcebd1a8/attachment.bin 

Preceding a method call with (void)

[Rami Rosen]

Hi,
Well, there are rare cases in the kernel when you add (void) before calling
the method. For example, if the method returns int or other type and you
want to emphasize that you are aware of that and deliberately not check the
return value.
See for example:
http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbxfload.c#L156

Regards,
Rami Rosen
?????? 10 ???? 2015 09:39, <Valdis.Kletnieks@vt.edu> ???:

> On Thu, 10 Sep 2015 07:52:49 +0300, Kevin Wilson said:
>
> > (void) myFunc(param1);
> >
> > I did not encounter such cases in the kernel code that I read, thus far.
> >
> > On the other hand, I did not saw in the kernel coding style doc
> > anything which prohibits such usage.
> >
> > If I remember, using (void) before the method name is a way to tell
> > explicitly that this method does not return any value,
> > but I am not sure as for the exact reasons it is used (in userspace).
>
> Well, if the function actually returns nothing, in kernel code we usually
> declare it as:
>
> void myFunc( int param1)
> {
> /* yadda yadda yadda *.
> }
>
> Given that, what reason is there for casting the return value with (void)?
>
> (And if the function is actually   'int myFunc ( int param1) {...}',
> why are you calling it and then ignoring the return value?  That's a clue
> that you're abusing the API...)
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/ae10377a/attachment-0001.html 

Preceding a method call with (void)

[Valdis.Kletnieks at vt.edu]

On Fri, 18 Sep 2015 17:04:03 +0300, Rami Rosen said:

> Well, there are rare cases in the kernel when you add (void) before calling
> the method. For example, if the method returns int or other type and you
> want to emphasize that you are aware of that and deliberately not check the
> return value.
> See for example:
> http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbxfload.c#L156

The fact something is done in the tree doesn't mean it's *correct*.

If you check the tree, there are 80 instances of it being cast to (void),
and 9 instances of 'status ='.

Now if you go look at the source of the function in drivers/acpi/acpica/utmutex.c
we discover that there's 3 or 4 possible return(..) conditions in the
function (one only if _DEBUG is defined).  Looking at the places that
places that bother checking the return code, they all look something like this:

nsxfeval.c:     status = acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
nsxfeval.c-     if (ACPI_FAILURE(status)) {
nsxfeval.c-             return (status);
nsxfeval.c-     }

Now, given that 80 other sites don't bother checking, there's a good
chance that these 9 call sites shouldn't bother either, and the calling
code should be changed to not check the status either, and then make
the function definition a void.

(Of course a more careful examination of the code should be undertaken, but
it's more likely that there's 9 sites that are checking a return code that
doesn't actually matter than the chances that it really *does* matter in
9 places but not in 80 others...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150918/4fc20184/attachment.bin