Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4CF5B1C9.8070005@rowe-clan.net>
Date: Tue, 30 Nov 2010 20:24:09 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r1040791 - /httpd/httpd/trunk/support/htcacheclean.c
References: 
 <urn:uuid:%3c20101130215902-245DB23889B2@eris-apache-org%3e@localhost.localdomain>
In-Reply-To: 
 <urn:uuid:%3c20101130215902-245DB23889B2@eris-apache-org%3e@localhost.localdomain>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/30/2010 3:59 PM, fuankg@apache.org wrote:
> Author: fuankg
> Date: Tue Nov 30 21:59:01 2010
> New Revision: 1040791
> 
> URL: http://svn.apache.org/viewvc?rev=1040791&view=rev
> Log:
> Some more casts to make MSVC calm ...
> 
> Modified:
>     httpd/httpd/trunk/support/htcacheclean.c
> 
> Modified: httpd/httpd/trunk/support/htcacheclean.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/support/htcacheclean.c?rev=1040791&r1=1040790&r2=1040791&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/support/htcacheclean.c (original)
> +++ httpd/httpd/trunk/support/htcacheclean.c Tue Nov 30 21:59:01 2010
> @@ -508,9 +508,9 @@ static int list_urls(char *path, apr_poo
>                                                      " %" APR_TIME_T_FMT
>                                                      " %d %d\n",
>                                                      url,
> -                                                    round_up(hinfo.size, round),
> +                                                    round_up((apr_size_t)hinfo.size, round),

Absolutely not.

apr_off_t is nearly always much smaller than apr_size_t.  Conveniently, there is
an APR_OFF_T_FMT at your service to solve this correctly.

The vast majority of casts are used inappropriately.  Appropriate casts should be
documented, and you will rarely find one that can't be better addressed by correct
normalization of all of the types/function declarations involved.  Since we are
no where near API freeze, there are basically no excuses.