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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Wei Liu writes ("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:
> > 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.

The header file says nothing about this.  It seems to imply that the
file is json, which, if it contains a nul, it isn't.  I do see that
the implementation does make the off-by-one obviously deliberate.

> 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.

I see.

Well, I think the read/write API is nicer if it includes a trailing
nul.  ISTR some other caller of those functions wanting a nul too.
And it would be better if the file were actual json, even if many json
actual pretty printers will tolerate the nul.

So, my preference would be for the original patch to be resubmitted
with a summary of this thread in the commit message.

Maybe in some future release, an additional patch to remove the nul,
although I care about that a lot less.  I don't see any reason to
remove the nul proactively given that it might break people doing
unsupported things like going backwards with their libxl version.

Ian.

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