Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 14 May 2012, Ian Jackson wrote:
> > > > +/* same as in Linux */
> > > > +static char *encode_disk_name(char *ptr, unsigned int n)
> > > > +{
> > > > +    if (n >= 26)
> > > > +        ptr = encode_disk_name(ptr, n / 26 - 1);
> > > > +    *ptr = 'a' + n % 26;
> > > > +    return ptr + 1;
> > > > +}
> > > 
> > > This still makes it difficult to see that the buffer cannot be
> > > overrun.  I mentioned this in response to a previous posting of this
> > > code and IIRC you were going to do something about it, if only a
> > > comment explaining what the maximum buffer length is and why it's
> > > safe.
> > 
> > I am keen on keeping the code as is, because it is the same that is in
> > Linux (see comment above).
> 
> I read the comment as "this implements the same transformation as the
> Linux kernel" not "this is the same code as actually used in the Linux
> kernel".  If you mean the latter, do say so.

Yes, it is actually the same used in the Linux kernel.


> Also, in that case why is the recursive function name, formatting,
> etc. not the same as in Linux (as far as they can be) ?  Surely if
> Linux changes this we will want to change our code too and that will
> be easiest if we can c&p without needing to reformat, rename, etc.

It is exactly the same code, except for the tab indentation that I
replaced with space indentation to follow the coding style.


> > I'll add a comment.
> 
> OK.  The comments, taken together, should constitute proofs that the
> code does not overrun any buffers.

The two comments refer to the upper bound that we introduced, thanks to
the limit there can be no buffer overruns.

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