On 21.11.2024 13:53, Frediano Ziglio wrote:
> On Wed, Oct 30, 2024 at 1:25 PM Andrew Cooper <[email protected]>
> wrote:
>>
>> On 21/10/2024 1:02 pm, [email protected] wrote:
>>> Hello everyone,
>>>
>>> As there were no objections to the proposed release schedule
>>> (https://lore.kernel.org/xen-devel/CAMacjJxEi6PThwH2=nwg3he8eqn39aiaxzcw3bqf7i4ycmj...@mail.gmail.com/
>>> ), I've updated the wiki with the schedule for Xen 4.20 release
>>> (https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes), and
>>> it is now accessible from
>>> https://xenbits.xen.org/docs/unstable-staging/support-matrix.html.
>>
>> I have a blocker to raise (against myself...) and no good idea of how to
>> proceed.
>>
>> The for_each_bit work has a unexpected bug.
>>
>> for_each_bit ( ... )
>> {
>> if ( ... )
>> break;
>> }
>>
>> will fall into an infinite loop. This is caused by for_each_bit()
>> hiding a double for() loop, in order to declare two scope-local
>> variables of different types.
>>
>> The two variables are one copy of the source expression (really quite
>> important to keep), and one unsigned int iterator (improved optimisation
>> capability by not using a wider-scope variable).
>>
>> Options are (off the top of my head)
>>
>> 1) Always take the iterator from outer scope
>> 2) Iterator always the same type as the source expression
>> 3) Figure out some way of expressing "once" in the outer loop
>>
>> Or anything else that I've missed.
>>
>> ~Andrew
>>
>
> Something like
>
> #define for_each_set_bit(iter, val) \
> for ( typeof(val) __v = (val), __c=1; __c; __c=0) \
> for ( unsigned int (iter); \
> __v && ((iter) = ffs_g(__v) - 1, true); \
> __v &= __v - 1 )
>
> ?
Hmm, right, but then we don't even need a 2nd variable, do we?
#define for_each_set_bit(iter, val) \
for ( typeof(val) __v = (val); __v; __v = 0 ) \
for ( unsigned int (iter); \
__v && ((iter) = ffs_g(__v) - 1, true); \
__v &= __v - 1 )
Jan
