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

Re: [Xen-devel] [PATCH] libxl: make sure buffer is null-terminated in libxl_read_file_contents [and 3 more messages]



On Thu, Jun 28, 2018 at 12:35:38PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH] libxl: make sure buffer is 
> null-terminated in libxl_read_file_contents [and 3 more messages]"):
> > We can safely remove the trailing nul if libxl API makes sure a buffer
> > is nul-terminated. Old files will still work with new library. New files
> > won't work with old library -- but we don't support that.
> 
> I guess.
> 
> > > I am inclined to think that something along the lines of the original
> > > patch is the way to do that.  Although, this extra nul byte should be
> > > documented in the API comment then.
> > > 
> > > Also, we should identify where the additional nul byte is coming
> > > from.  While we can't just delete that, we should put a comment in
> > > saying that the off-by-one error is deliberate.
> > 
> > What off-by-one error?
> 
> The one that writes a nul to the file.  I can't believe it was
> deliberate.  I haven't looked to find where it comes from but if the
> code where it comes from doesn't look like an off-by-one error then it
> is too obtuse :-).

It is deliberate. See libxl_internal.h:libxl__set_domain_configuration.

At the time I wrote the code I didn't want to change the read/write
function APIs. The file was / is considered internal anyway.

Wei.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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