On Mon, Jun 24, 2019 at 09:30:26PM +0200, Max Reitz wrote:
> On 24.06.19 21:26, Max Reitz wrote:
> > On 24.06.19 21:21, Eduardo Habkost wrote:
> >> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
> >>> find_next_bit() takes a pointer of type "const unsigned long *", but the
> >>> first a
On 24.06.19 21:26, Max Reitz wrote:
> On 24.06.19 21:21, Eduardo Habkost wrote:
>> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
>>> find_next_bit() takes a pointer of type "const unsigned long *", but the
>>> first argument passed here is a "uint64_t *". These types are
>>> incompati
On 24.06.19 21:21, Eduardo Habkost wrote:
> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
>> find_next_bit() takes a pointer of type "const unsigned long *", but the
>> first argument passed here is a "uint64_t *". These types are
>> incompatible when compiling qemu with -m32.
>>
>> J
On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
> find_next_bit() takes a pointer of type "const unsigned long *", but the
> first argument passed here is a "uint64_t *". These types are
> incompatible when compiling qemu with -m32.
>
> Just cast it to "const void *", find_next_bit() w
find_next_bit() takes a pointer of type "const unsigned long *", but the
first argument passed here is a "uint64_t *". These types are
incompatible when compiling qemu with -m32.
Just cast it to "const void *", find_next_bit() works fine with any type
on little-endian hosts (which x86 is).
Fixes
