On Sat, 2005-05-07 at 13:39 +0200, Branko Èibej wrote:
> I'm not Philip, but I suggest we change the docstring to "may be
> allocated in @a pool". We do that in other places where a function may
> return a statically or dynamically allocated object.
I object, based on Peter's dynamic loading scenario. I think returning
a static string is generally a meaningless performance optimization, and
even the most bizarre of borderline cases should be considered a
showstopper bug for a meaningless optimization.
Apart from that, "the return value may be allocated in pool" is too
vague. If it's not allocated in pool, there are a variety of other
options the implementation might use, such as a pool associated with one
of the passed-in objects.
> >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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 7 18:07:43 2005