lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 02 Feb 2015 11:10:01 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Nicholas Mc Guire <der.herr@...r.at>
CC:	Nicholas Mc Guire <hofrat@...dl.org>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	Hartmut Knaack <knaack.h@....de>,
	Peter Meerwald <pmeerw@...erw.net>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] iio: ad_sigma_delta: cleanup wait_for_completion
 return handling

On 02/02/2015 10:50 AM, Nicholas Mc Guire wrote:
> On Mon, 02 Feb 2015, Lars-Peter Clausen wrote:
>
>> On 02/02/2015 09:37 AM, Nicholas Mc Guire wrote:
>>> return type of wait_for_completion_timeout is unsigned long not int, rather
>>> than introducing a new variable the wait_for_completion_timeout is moved
>>> into the if condition as the return value is only used to detect timeout.
>>
>> But the return value is bound by the timeout parameter and we know that
>> fits into a int. And I really dont like moving the function call into the
>> if condition, so unless there is some additional explanation why this is
>> necessary and should be done I'm inclined to nack this.
>>
>
> well having correct types is important for all static code chekcers
> and I did not want to add a new variable just for this case
> simply because the result is only relevant in the == 0 case
> anyway.
>
> I do think that the types being assigned should correct with respect
> to the API definition even if it fits in this case.
>
>>>
>>> Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
>>> ---
>>>
>>> Aside from the fixup of the wait_for_completion_timeout handling
>>> a minor coding style issue in the else branch was fixed - the {} is
>>> not needed for the one-line body.
>>
>> If one of the branches of a conditional statement has braces the other
>> branches should also have braces. This is documented in
>> Documentation/CodingStyle.
>
> my bad - it is not uncommon to be asymetric - but you are right that Chapter 3
> states it should not be asymetric in this case - will remove that.
>
> given the botched braces this needs to be redone - let me know if moving
> it into the condition is ok (its not uncommon) or if an additional variable
> of type unsigned long is the prefered solution.

I prefer the extra variable, but that's personal taste. And maybe add the 
stuff about the static code checker etc to the commit message.

Thanks,
- Lars

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ