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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 18 May 2012, Ian Jackson wrote:
> 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.
 
If my math is correct there is no need to enforce an upper limit because
even if we suppose that offset is ULONG_MAX on 64 bits it would still be
lower than 26 elevated at 28 that is the actual upper limit.
I am going to write this in a comment.

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