r18295 - gnucash/trunk/src - Fix more valgrind problems

[Christian Stimming]

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!

Regards,

Christian

> API have caller supply the data?  If swig could generate a wrapper that
> would do that, great.
>
> 1000 limit?  Seemed to be enough at the time.
>
> Phil
>
>
>
>
> ________________________________
> From: Derek Atkins <warlord at MIT.EDU>
> To: gnucash-devel at gnucash.org
> Sent: Tuesday, September 8, 2009 10:03:44 AM
> Subject: Re: r18295 - gnucash/trunk/src - Fix more valgrind problems
>
> Phil,
>
> Phil Longstaff <plongstaff at code.gnucash.org> writes:
>
> [snip]
>
> > +/**
> > + * Returns the account full name.  Unlike xaccAccountGetFullName(), the
> > + * string returned must *NOT* be freed.
> > + *
> > + * @param account Account
> > + * @return Account full name
> > + */
>
> Moreover this function is no longer thread-safe at all, as it uses
> static data.  So you must be sure to copy out the results before anyone
> else calls it.
>
> Any reason not to change the API to have the caller supply the data?
> Why the arbitrary 1000 char limit?
>
> -derek