Re: [Xen-devel] [PATCH] Fix stubdom build failure for RELEASE-4.3.1

[Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>]

Andrew Cooper, le Thu 31 Oct 2013 14:57:24 +0000, a écrit :
>     diff --git a/extras/mini-os/pcifront.c b/extras/mini-os/pcifront.c
>     index bbe21e0..9d0cb17 100644
>     --- a/extras/mini-os/pcifront.c
>     +++ b/extras/mini-os/pcifront.c
>     @@ -413,7 +413,7 @@ int pcifront_physical_to_virtual (struct pcifront_dev
>     *dev,
>                      continue;
>                  }
>      
>     -            if (sscanf(s, "%x:%x:%x.%x", dom, bus, slot, fun) != 4) {
>     +            if (sscanf(s, "%x:%x:%x.%lx", dom, bus, slot, fun) != 4) {
> 
> 
> This is a little awkward.  It has been changed in unstable and is now 
> correct. 

Mmm, I don't see it fixed in unstable.  I wonder why fun is an
unsigned long at all, it is even passed unsigned ints in callers.
pcifront_physical_to_virtual and pcifront_conf_read should just use
unsigned int.

>     @@ -769,7 +769,7 @@ domid_t xenbus_get_self_id(void)
>          domid_t ret;
>      
>          BUG_ON(xenbus_read(XBT_NIL, "domid", &dom_id));
>     -    sscanf(dom_id, "%d", &ret);
>     +    sscanf(dom_id, "%u", (unsigned int*)&ret);
> 
> 
> This needs to be
> 
> sscanf(dom_id, "%"SCNd16, &ret);

Mmm, perhaps rather make ret itself an unsigned int? I'd rather not
hardcode here what a domid_t is.

I agree on the rest.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel