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
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
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...)
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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...
participants (4)
-
Greg KH -
Kevin Wilson -
Rami Rosen -
Valdis.Kletnieks＠vt.edu