On September 8, 2009 04:43:48 pm Christian Stimming wrote: > Am Dienstag, 8. September 2009 16:30 schrieb Phil Longstaff: > > Yes. The purpose of this call was for scm so that the returned string > > wouldn't be leaked. If swig could wrap a call and free the result, that > > would be an even better solution. > > We have plenty of functions throughout gnc-qof and the engine which return > newly allocated strings that need to be free'd by the caller. I was pretty > sure swig can handle that situation correctly. At least that's my vague > memory of when I was working with this more intensively. > > Your patch r18295 and also r18294 unfortunately seem to introduce yet more > possibilities for error, both of which have already been mentioned. I would > strongly prefer to have swig free the result by itself, or rather keep > living with the memory leak until someone has found out how to tweak swig > so that it does that. In this case, the reason "valgrind has pointed out > this to be a problem" IMHO isn't enough of a reason to introduce this > blatantly obvious other sources of error, only to make the valgrind > warnings silent. Please solve this in a different way. Thanks a lot!
OK. Swig can handle the situation correctly if it is told in the correct way to do so. To do that, you need a '%newobject XXX' line before it comes across the declaration of function XXX. I'll remove the new functions and update the .i files appropriately. Phil _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
