Re: [Xen-devel] [PATCH v6 07/11] libxl: introduce libxl__alloc_vdev

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Stefano Stabellini writes ("[PATCH v6 07/11] libxl: introduce 
libxl__alloc_vdev"):
> Introduce libxl__alloc_vdev: find a spare virtual block device in the
> domain passed as argument.
...
> +/* Same as in Linux.
> + * The maximum buffer length is 32 bytes.
> + * The code is safe thanks to the upper bound enforced by the caller. */
> +static char *encode_disk_name(char *ptr, unsigned int n)

So this says that encode_disk_name may use up to 32 bytes in *ptr
(including or excluding the trailing nul?)

_Why_ may the maximum buffer length used be 32 bytes ?  Also, "maximum
buffer length" is a confusing phrase because it seems to refer to the
/actual/ length of the buffer rather than the amount /used/.

And this...

> +    char *ret = libxl__zalloc(gc, 32);

... allocates a 32 byte buffer which we then fill with ...

> +    strcpy(ret, "xvd");
> +    ptr = encode_disk_name(ret + 3, offset);

3 characters plus the encoded disk name.  So possibly using up to 36
bytes.

In fact it seems to me that there could be a much tighter upper bound
on the length of output of encode_disk_name (based on arithmetic) but
it needs to be properly calculated and documented and perhaps put in a
#define.

Ian.

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