>>> On 22.06.15 at 18:24, <vkuzn...@redhat.com> wrote: > "Jan Beulich" <jbeul...@suse.com> writes: > >>>>> On 22.06.15 at 18:00, <vkuzn...@redhat.com> wrote: >>> "Jan Beulich" <jbeul...@suse.com> writes: >>> >>>>>>> On 03.06.15 at 15:35, <vkuzn...@redhat.com> wrote: >>>>> @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v) >>>>> mfn = v->vcpu_info_mfn; >>>>> unmap_domain_page_global((void *) >>>>> ((unsigned long)v->vcpu_info & PAGE_MASK)); >>>>> - >>>>> - v->vcpu_info = &dummy_vcpu_info; >>>>> + v->vcpu_info = ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS) >>>>> + ? (vcpu_info_t *)&shared_info(d, >>>>> vcpu_info[v->vcpu_id]) >>>> >>>> Is this cast really needed? >>>> >>> >>> Without it my gcc-4.8.3 complains: >>> >>> domain.c: In function ‘unmap_vcpu_info’: >>> domain.c:1158:21: error: pointer type mismatch in conditional expression >>> [-Werror] >>> : &dummy_vcpu_info); >>> ^ >>> cc1: all warnings being treated as errors >> >> Which is the kind of warning one normally should _not_ work >> around by adding a cast. > > In this (and in alloc_vcpu() from where this expression was copied) > particular case this is probably OK: in struct shared_info we have > 'struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS]' as its first > member. But I may be missing something..
Did you read the comment accompanying the definition of __shared_info()? The cast is presumably safe here, but it doesn't _look_ safe. And for future readers (and future changes) it would be better if it did. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
