[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Stefano Stabellini writes ("[PATCH v6 07/11] libxl: introduce 
> 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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.