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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 21 May 2012, Stefano Stabellini wrote:
> 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 meant 26 raised to the power of 28


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