Re: [Qemu-devel] [PATCH] bitops: fix types

[Peter Maydell]

On 8 July 2012 20:39, Blue Swirl <address@hidden> wrote:
> On Sun, Jul 8, 2012 at 7:32 PM, Peter Maydell <address@hidden> wrote:
>> On 8 July 2012 20:12, Blue Swirl <address@hidden> wrote:
>>> On Sun, Jul 8, 2012 at 6:54 PM, Peter Maydell <address@hidden> wrote:
>>>> On 8 July 2012 19:32, Blue Swirl <address@hidden> wrote:
>>>>> On Sun, Jul 8, 2012 at 2:04 PM, Peter Maydell <address@hidden> wrote:
>>>>>> On 8 July 2012 13:12,  <address@hidden> wrote:
>>>>>>> -static inline uint64_t deposit64(uint64_t value, int start, int length,
>>>>>>> -                                 uint64_t fieldval)
>>>>>>> +static inline uint64_t deposit64(uint64_t value, unsigned int start,
>>>>>>> +                                 unsigned int length, uint64_t 
>>>>>>> fieldval)
>>>>>>>  {
>>>>>>>      uint64_t mask;
>>>>>>> -    assert(start >= 0 && length > 0 && length <= 64 - start);
>>>>>>> +    assert(length > 0 && length <= 64 - start);
>>>>>>
>>>>>> This breaks the assertion (consider the case of start == UINT_MAX
>>>>>> and length == 64).
>>>>>
>>>>> The original is equally buggy in other cases since there is no bound
>>>>> check for the upper limit.
>>>>
>>>> For what upper limit? Overlong length or start should both be caught
>>>> by the third condition in the signed case.
>>>
>>> Nice. Why is it written like that, I'd use
>>> start + length <= 64?
>>
>> That would fail to handle the case of start == length == INT_MAX.
>
>  64 - INT_MAX = 0x80000040 (maybe off by one), which should still
> trigger assert(INT_MAX <= 0x80000040).

Nope, because "64 - start" here is signed arithmetic, so 64 - INT_MAX
underflows and gives you a negative number, and INT_MAX is not <= -ve.
(We went through this in reviews for the initial patch.)

-- PMM