Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.1.2.2.20050518102708.05adb110@pop3.rowe-clan.net>
Date: Wed, 18 May 2005 10:58:47 -0500
To: Joe Orton <jorton@redhat.com>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: LP64/P64 model API issue #2
Cc: dev@apr.apache.org
In-Reply-To: <20050518143535.GA12745@redhat.com>
References: <6.2.1.2.2.20050516133724.07370a90@pop3.rowe-clan.net>
 <20050517140136.GB5421@redhat.com>
 <6.2.1.2.2.20050518023918.04b1d790@pop3.rowe-clan.net>
 <20050518143535.GA12745@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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?