Fair warning, as this keeps coming up over and over. We're not using

apr_pool_userdata_setn() anymore as far as I can tell, because anywhere
that we used it was later deemed unsafe for one reason or another.  Is
it wise to have it in the API at all?  I suppose it has value, but
knowing when it's safe to use it can be tricky.


git-svn-id: http://svn.apache.org/repos/asf/apr/apr/trunk@63432 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 8 insertions, 2 deletions

diff --git a/include/apr_pools.h b/include/apr_pools.h
index 28140bc28..275624b17 100644
--- a/include/apr_pools.h
+++ b/include/apr_pools.h
@@ -488,8 +488,14 @@ APR_DECLARE(apr_status_t) apr_pool_userdata_set(
  * @note same as apr_pool_userdata_set(), except that this version doesn't
  *       make a copy of the key (this function is useful, for example, when
  *       the key is a string literal)
- * @warning The key and the data to be attached to the pool should have
- *       a life span at least as long as the pool itself.
+ * @warning This should NOT be used if the key could change addresses by
+ *       any means between the apr_pool_userdata_setn() call and a
+ *       subsequent apr_pool_userdata_get() on that key, such as if a
+ *       static string is used as a userdata key in a DSO and the DSO could
+ *       be unloaded and reloaded between the _setn() and the _get().  You
+ *       MUST use apr_pool_userdata_set() in such cases.
+ * @warning More generally, the key and the data to be attached to the
+ *       pool should have a life span at least as long as the pool itself.
  *
  */
 APR_DECLARE(apr_status_t) apr_pool_userdata_setn(