Re: [Qemu-devel] [PATCH v2 1/3] bitops: fix types

[Blue Swirl]

On Tue, Jul 10, 2012 at 9:36 PM, Peter Maydell <address@hidden> wrote:
> On 10 July 2012 21:01, Blue Swirl <address@hidden> wrote:
>> On Tue, Jul 10, 2012 at 7:37 PM, Peter Maydell <address@hidden> wrote:
>>> On 10 July 2012 20:18, Blue Swirl <address@hidden> wrote:
>>>> On Mon, Jul 9, 2012 at 7:49 AM, Markus Armbruster <address@hidden> wrote:
>>>>> There is no consensus.  I recognize the power of maintainers to force a
>>>>> change even without consensus.  Use it wisely.
>>>>
>>>> I thought I refuted all concrete arguments except performance.
>>>
>>> No, you made various claims that Markus and I at least
>>> disagreed with. (Conversely, we have made various claims
>>> that you disagree with -- this is what "no consensus" means...)
>>
>> You did not present any concrete arguments. In this review you have
>> pointed at bugs in the assert() expression, thanks.
>
> No, a bug in your assert is an indication of why there are
> downsides to making random changes, not a concrete argument
> against making the changes. The major problem here
> is (a) there is no really good reason to make this change

There are inconsistencies in the API that need fixing (unsigned long
vs. int) and a technically improved solution (unsigned int in x86_64)
exists. These are good and valid reasons.

> (b) it's moving away from the existing tested code we have
> (and that the kernel has).

Keeping the code intact should not stop progress: fix inconsistencies
and use a better solution. The distance from kernel is questionable
value BTW: have you checked how little bitops.h resembles the kernel
versions?

> Basically 'int' has more natural
> behaviour for reasoning about than 'unsigned' in ranges
> where it's usually used (ie small ones).

But 'unsigned' is much more naturally suited to values that can't be
negative. This part is bikeshedding, your point of view against mine.
Currently some functions use 'unsigned long' for bit numbers,
shouldn't they be changed to 'int' in your logic?

>
> -- PMM