On Sat, 7 May 2005, [UTF-8] Branko Ä^Libej wrote:
> Peter N. Lundblad wrote:
>
> >Philip, if you want the docstring to be changed, please say so
> >explicitly in your next reply.
> >
> >
> 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'm fine with that change if anyone cares.
> >For the second question, I think the answer is "no". Here's an example:
> >
> >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).
The lifetime is the same as the program's lifetime - in a world without
dynamic loading.
>
> >I can't say this scenario (or some variant thereof) is unreasonable and
> >therefore I think "allocated in @a pool" should really mean what it says.
> >
> >
> I agree with that. But I also think that adding a "may be" there is
> quite sufficient for our purposes. Certainly the function as it stands
> now should return the static pointer.
>
As I said, it is a very minimal optimization, but I don't object either.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 7 17:06:57 2005