apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: LP64/P64 model API issue #2
Date Wed, 18 May 2005 15:58:47 GMT
At 09:35 AM 5/18/2005, Joe Orton wrote:
>On Wed, May 18, 2005 at 02:41:48AM -0500, William Rowe wrote:
>> At 09:01 AM 5/17/2005, Joe Orton wrote:
>> >On Mon, May 16, 2005 at 01:39:20PM -0500, William Rowe wrote:
>> >> Issue  #1; How to manipulate nelts in apr_table_entry?
>> >> 
>> >> We can preserve the existing behavior of nelts, defining it as
>> >> a simple int.  A few casts are required out of the result of some
>> >> pointer arithmetic.
>> >
>> >Can you explain what casts are needed exactly, and why?
>> 
>> It's embodied by the patch below - the delta of two pointer
>> offsets result in a size_t (by definition).  On LP64/P64, the
>> sizeof(int) < sizeof(size_t).
>
>The code is really fine in both places - you're really out here to fix
>compiler warnings, right?

No, I'm using the compiler warnings to identify code with the
wrong apr_size_t/apr_off_t/int choice of arguments.  The patch 
only fixes emits we are willing to accept...

>  But a different compiler could now issue a
>new warning in table_mergesort:
>
>    for (i = 0; i + 1 < n; i += 2) {
>
>for comparison of (apr_size_t) i and (int) n since they have both
>different size and signedness.  So that's not improved the code quality
>a great deal really.

Very true.  As table_mergesort is a static local function, this
is easy to clear up without a cast.

That said; on an LP64 platform, we *could* use size_t instead of int
as the nelts domain in apr-util v2.0.  Question: Do we want to?



Mime
View raw message