[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: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-05-07 13:39:03 CEST

Peter N. Lundblad wrote:

>We have lots of API routines that returns strings "allocated in @a pool".
>So, I think we have two questions here:
>- What should the docstrin gsay
>and
>- if the docstring says "allocated in @a pool", is the function allowed to
> return a statically allocated string?
>
>For the first question,
>
[snip]

>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.

>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).

>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.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 7 13:39:49 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.