| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
that.
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?
Gianni
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home