>>> On 18.01.16 at 16:38, <roger....@citrix.com> wrote:
> El 18/01/16 a les 16.24, Andrew Cooper ha escrit:
>> On 18/01/16 15:21, Jan Beulich wrote:
>>>>>> On 18.01.16 at 16:09, <roger....@citrix.com> wrote:
>>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>>> @@ -161,8 +161,8 @@ struct hvm_hw_cpu {
>>>> uint32_t error_code;
>>>>
>>>> #define _XEN_X86_FPU_INITIALISED 0
>>>> -#define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
>>>> - uint32_t flags;
>>>> +#define XEN_X86_FPU_INITIALISED (1UL<<_XEN_X86_FPU_INITIALISED)
>>>> + uint64_t flags;
>>>> };
>>> How is the UL going to make this safe for a 32-bit consumer?
>>> Makes me think that, other than just said in reply to v1, it'll
>>> indeed be better to have a separate field (with a separate
>>> zero-check)... The (undesirable imo) alternative being to use
>>> 1L instead.
>>
>> I am happy either way. My R-b stands.
>
> What about using ULL or simply casting to uint64_t?
ULL might not be supported by pre-C99 compilers. Casting to
uint64_t is, well, ugly. The flags field really has no business
being wider then 32 bits.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
