On 29.03.2024 19:23, Oleksii wrote:
> On Wed, 2024-03-20 at 16:42 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> --- a/xen/lib/find-next-bit.c
>>> +++ b/xen/lib/find-next-bit.c
>>> @@ -9,6 +9,7 @@
>>> * 2 of the License, or (at your option) any later version.
>>>
On Wed, 2024-03-20 at 16:42 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > --- a/xen/lib/find-next-bit.c
> > +++ b/xen/lib/find-next-bit.c
> > @@ -9,6 +9,7 @@
> > * 2 of the License, or (at your option) any later version.
> > */
> > #include
> > +#include
> >
On Wed, 2024-03-20 at 16:42 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > --- a/xen/lib/find-next-bit.c
> > +++ b/xen/lib/find-next-bit.c
> > @@ -9,6 +9,7 @@
> > * 2 of the License, or (at your option) any later version.
> > */
> > #include
> > +#include
> >
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- a/xen/lib/find-next-bit.c
> +++ b/xen/lib/find-next-bit.c
> @@ -9,6 +9,7 @@
> * 2 of the License, or (at your option) any later version.
> */
> #include
> +#include
>
> #include
Hmm, no, a library source would better not include this he
The mentioned macros exist only because of Linux compatible purpose.
The patch defines __ffs() in terms of Xen bitops and it is safe
to define in this way ( as __ffs() - 1 ) as considering that __ffs()
was defined as __builtin_ctzl(x), which has undefined behavior when x=0,
so it is assumed that s
