[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: API docs and pool usage

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-05-07 21:07:04 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> On Sat, 2005-05-07 at 13:39 +0200, Branko Èibej wrote:
>> >Say we have an application plugin (for whatever application you can think
>> >of) that uses our libraries. The app load the plugin that links to our
>> >libs. The plugin calls an svn functiion that returns a value "allocated in
>> >@a pool"; @a pool is controlled by the application. The plugin gives the
>> >return value to the app, which it thinks is OK, since the alue is
>> >allocated in a pool that the app controls. The app unloads the plugin and
>> >then uses the data returned. Crash!
>
>> Well, obvioiusly lifetime is important, and whatever you return must
>> have a lifetime that is /at least/ the same as the lifetime of the pool,
>> but there's nothing wrong with it being longer (and static strings have
>> an "infinite" lifetime).
>
> I think you missed how Peter's scenario makes a static string have a
> shorter lifetime than the passed-in pool.

I guess that's a valid concern in general, in this specific case the
static string is within svn_cmdline_init() and the documentation
states:

/** Set up the locale for character conversion, and initialize APR.
 * If @a error_stream is non-null, print error messages to the stream,
 * using @a progname as the program name. Return @c EXIT_SUCCESS if
 * successful, otherwise @c EXIT_FAILURE.
 *
 * @note This function should be called exactly once at program startup,
 * before calling any other APR or Subversion functions.
 */

I suppose an application might attempt to access the memory after this
has unloaded, but it seems improbable.

In the end I don't really care, the allocation only happens on Windows
I don't use that :)

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 7 21:07:54 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.