On Wed, Aug 10, 2022 at 1:06 AM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Tue, Aug 9, 2022 at 8:43 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> From: Bin Meng <bin.meng@windriver.com>
>>
>> The maximum number of wait objects for win32 should be
>> MAXIMUM_WAIT_OBJECTS, not MAXIMUM_WAIT_OBJECTS + 1.
>>
>> Fix the logic in qemu_add_wait_object() to avoid adding
>> the same HANDLE twice.
>>
>
> Please make that a separate patch.
>
>>
>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>> ---
>>
>> Changes in v2:
>> - fix the logic in qemu_add_wait_object() to avoid adding
>> the same HANDLE twice
>>
>
> Still NACK, did you understand my argument about array bounds?
>
> "if (found)" will access the arrays at position i+1 == MAXIMUM_WAIT_OBJECTS. We need the +1 for that logic to work without OOB access.
>
The delete logic was updated in v2. If position is at
MAXIMUM_WAIT_OBJECTS - 1, the loop will break.
Ah I missed that. That new condition looks wrong to me. Not only it is redundant with the loop condition check if w->num == MAXIMUM_WAIT_OBJECTS
But you still access the array at MAXIMUM_WAIT_OBJECTS index, which requires arrays of MAXIMUM_WAIT_OBJECTS+1 size, since it's 0-indexed..
Unless I say crap, which happens sometime :)
--
Marc-André Lureau