On 09/18/2012 08:29 AM, Eric Blake wrote:
On 09/18/2012 01:27 AM, Osier Yang wrote:
> On 2012年09月14日 15:46, Hu Tao wrote:
>> In many places we store bitmap info in a chunk of data
>> (pointed to by a char *), and have redundant codes to
>> set/unset bits. This patch extends virBitmap, and convert
>> those codes to use virBitmap in subsequent patches.
>> ---
>> +
>> + memcpy(bitmap->map, data, len);
>> + for (i = 0; i< bitmap->map_len; i++)
>> + bitmap->map[i] = le64toh(bitmap->map[i]);
>
>
> le64toh is not portable. Such as on mingw platform.
Agreed - gnulib does not yet provide it, so we need to open-code this
ourselves instead of relying on a non-standard function.
Also, this is broken on 32-bit platforms.
https://www.redhat.com/archives/libvir-list/2012-September/msg01326.html
>> + l = (unsigned long *)*data;
>> + for (i = 0; i< bitmap->map_len; i++, l++)
>> + *l = htole64(*l);
>
> Likewise.
Same here.
Even worse, this use of htole64 can trigger unaligned data access, and
trigger SIGBUS on platforms not as forgiving as x86_64.
>> +
>> + return ffsl(bits) - 1 + nl * VIR_BITMAP_BITS_PER_UNIT;
>
> And ffsl.
But here, gnulib guarantees ffsl. We just need to modify bootstrap.conf
to pull it in.
As well as include the right header (the fact that glibc leaks ffs, and
therefore ffsl, through <string.h>, does not mean that it happens like
that on other platforms).
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org