On 01/08/16 11:29, Jan Beulich wrote:
On 14.07.16 at 17:58, wrote:
>> --- a/xen/include/xen/types.h
>> +++ b/xen/include/xen/types.h
>> @@ -1,6 +1,8 @@
>> #ifndef __TYPES_H__
>> #define __TYPES_H__
>>
>> +#include
>> +
>> #include
>>
>> #define BITS_TO_LONGS(bits) \
>> @@ -59,4 +61,
>>> On 14.07.16 at 17:58, wrote:
> --- a/xen/include/xen/types.h
> +++ b/xen/include/xen/types.h
> @@ -1,6 +1,8 @@
> #ifndef __TYPES_H__
> #define __TYPES_H__
>
> +#include
> +
> #include
>
> #define BITS_TO_LONGS(bits) \
> @@ -59,4 +61,8 @@ typedef __u64 __be64;
>
> typedef unsigned
At 16:58 +0100 on 14 Jul (1468515536), Andrew Cooper wrote:
> and switch bool_t to being of type _Bool rather than char.
>
> Using bool_t as char causes several subtle problems; first that a bool_t
> actually has more than two values, and that (bool_t)0x100 actually has the
> value 0 rather than t
On 14/07/16 17:12, Julien Grall wrote:
> Hi Andrew,
>
> On 14/07/16 16:58, Andrew Cooper wrote:
>> and switch bool_t to being of type _Bool rather than char.
>>
>> Using bool_t as char causes several subtle problems; first that a bool_t
>> actually has more than two values, and that (bool_t)0x100 a
Hi Andrew,
On 14/07/16 16:58, Andrew Cooper wrote:
and switch bool_t to being of type _Bool rather than char.
Using bool_t as char causes several subtle problems; first that a bool_t
actually has more than two values, and that (bool_t)0x100 actually has the
value 0 rather than the expected 1, d
and switch bool_t to being of type _Bool rather than char.
Using bool_t as char causes several subtle problems; first that a bool_t
actually has more than two values, and that (bool_t)0x100 actually has the
value 0 rather than the expected 1, due to truncation.
Making this change reveals two bugs
