This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 07 of 10] pyxl: Recursively scan type-tree to pro

On Wed, 2011-01-12 at 13:00 +0000, Ian Jackson wrote:
> I wrote:
> > If you need to do something which changes the autogenerated code then
> > I'll be wanting a second opinion at least.
> Specifically, I'd like some a discussion of each change to the
> autogenerated output, and why it is necessary/justifiable/safe.

OK, well the code I resubmitted just then no longer makes that change to
auto-generated code. Btw. we are talking about whether that field gets
free()'d in the destructor function.

The problem is that this field is used once in libxl and it's assigned
as "", a static const char *. In the original version of the patch I
submitted the change leads to free() being called on that which is
erroneous. Changing it to not be const is a problem because callers will
need to know to strdup() now but the compiler wont be able to tell them

So, on the flip-side, my solution (patch v2) has just been to cast this
(const char *) to (char *) when we modify it from python bindings. This
is mostly fine correct the bindings handle all allocations. The problem
is that we just call the destructor function when the object in
question's (domain_build_info) goes away.

A workaround is to assign None to the field after it has been set to a
string but before the variable goes out of scope and gets collected.
It's a leak, but it's a small one. It would be a matter of a few more
lines of code in gewrap.py to make that go away. Perhaps I should make
these changes and re-submit end portion of series?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>