Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
Date: 26 Sep 2003 19:13:28 -0000
Message-ID: <20030926191328.6808.qmail@minotaur.apache.org>
From: jwoolley@apache.org
To: apr-cvs@apache.org
Subject: cvs commit: apr/include apr_pools.h

jwoolley    2003/09/26 12:13:28

  Modified:    include  apr_pools.h
  Log:
  clarify docs.
  submitted by: stas
  
  Revision  Changes    Path
  1.107     +6 -5      apr/include/apr_pools.h
  
  Index: apr_pools.h
  ===================================================================
  RCS file: /home/cvs/apr/include/apr_pools.h,v
  retrieving revision 1.106
  retrieving revision 1.107
  diff -u -d -u -r1.106 -r1.107
  --- apr_pools.h	26 Sep 2003 18:25:35 -0000	1.106
  +++ apr_pools.h	26 Sep 2003 19:13:28 -0000	1.107
  @@ -460,11 +460,12 @@
    *
    *      Users of APR must take EXTREME care when choosing a key to
    *      use for their data.  It is possible to accidentally overwrite
  - *      data by choosing a key that another part of the program is using
  - *      It is advised that steps are taken to ensure that unique keys are
  - *      used for all of the userdata objects in a given pool at all times.
  - *      Careful namespace prefixing of key names typically helps to ensure this
  - *      uniqueness.
  + *      data by choosing a key that another part of the program is using.
  + *      Therefore it is advised that steps are taken to ensure that unique
  + *      keys are used for all of the userdata objects in a particular pool
  + *      (the same key in two different pools or a pool and one of its
  + *      subpools is okay) at all times.  Careful namespace prefixing of
  + *      key names is a typical way to help ensure this uniqueness.
    *
    */
   APR_DECLARE(apr_status_t) apr_pool_userdata_set(