Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: svn commit: r1697828 -
 /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c
To: dev@subversion.apache.org
References: <20150826071500.46E7AAC0479@hades.apache.org>
From: =?UTF-8?Q?Branko_=c4=8cibej?= <brane@wandisco.com>
Organization: WANdisco
Message-ID: <55DD6814.5040906@wandisco.com>
Date: Wed, 26 Aug 2015 09:17:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150826071500.46E7AAC0479@hades.apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 26.08.2015 09:14, brane@apache.org wrote:
> Author: brane
> Date: Wed Aug 26 07:14:59 2015
> New Revision: 1697828
>
> URL: http://svn.apache.org/r1697828
> Log:
> Fix a 64-bit to 32-bit conversion warning on 64-bit platforms.
>
> * subversion/libsvn_subr/cache-membuffer.c
>   (prefix_pool_get_internal): Safely cast a pointer to an index, with range check.
>
> Modified:
>     subversion/trunk/subversion/libsvn_subr/cache-membuffer.c
>
> Modified: subversion/trunk/subversion/libsvn_subr/cache-membuffer.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/cache-membuffer.c?rev=1697828&r1=1697827&r2=1697828&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_subr/cache-membuffer.c (original)
> +++ subversion/trunk/subversion/libsvn_subr/cache-membuffer.c Wed Aug 26 07:14:59 2015
> @@ -339,7 +339,9 @@ prefix_pool_get_internal(apr_uint32_t *p
>    value = apr_hash_get(prefix_pool->map, prefix, prefix_len);
>    if (value != NULL)
>      {
> -      *prefix_idx = value - prefix_pool->values;
> +      const apr_size_t index = value - prefix_pool->values;
> +      SVN_ERR_ASSERT(index < prefix_pool->values_used);
> +      *prefix_idx = (apr_uint32_t) index;
>        return SVN_NO_ERROR;
>      }

Stefan2, please double-check this change. It's not strictly correct
since the type of the expression is ptrdiff_t, not size_t. In any case,
I wasn't comfortable with just blindly casting the result.

-- Brane