Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030113135858.02c05540@pop3.rowe-clan.net>
Date: Mon, 13 Jan 2003 14:01:51 -0600
To: Justin Erenkrantz <jerenkrantz@apache.org>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: cvs commit: apr/include apr_hash.h
Cc: dev@apr.apache.org
In-Reply-To: <2147483647.1042456722@[10.0.1.34]>
References: <20030113185207.64732.qmail@icarus.apache.org>
 <20030113185207.64732.qmail@icarus.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:18 PM 1/13/2003, Justin Erenkrantz wrote:
>--On Monday, January 13, 2003 6:52 PM +0000 wrowe@apache.org wrote:
>
>>wrowe       2003/01/13 10:52:07
>>
>>  Modified:    tables   apr_hash.c
>>               include  apr_hash.h
>>  Log:
>>    A binary-safe patch that satisfies Jerenkrantz's original
>>desire for     more elements, but structured such that we still use
>>the optimal platform     element indexes (a machine int is
>>generally faster than a fractional int).
>
>Um, apr_uint32_t is unsigned int.

Which is why the patch transformed them into unsigned int's... the size
remains the same on 64 bit CPUs, and since sizeof(int) == sizeof(unsigned int)
we shouldn't have problems with older builds.

>  Actually, I wonder what would happen when sizeof(int) isn't 4 on a Unix system.  APR's configure would produce an invalid apr.h.

How do you mean?  Are unicies 64 LP architectures?  I'm fairly certain we
can find 64 ILP architectures, so we better use caution here.

>It also seems to be common to use apr_uint32_t for indexes (see apr_allocator.h).  -- justin

Irrelevant, we didn't change that size after we incorporated it, so choosing
apr_unit32_t didn't harm anything.  Those are private values.  For performance 
reasons perhaps we should change it to unsigned int in APR 1.0, but that's 
something to chew on for the future, not for the 0.9 branch.

Bill