Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4B553666.2050606@peknet.com>
Date: Mon, 18 Jan 2010 22:34:46 -0600
From: Peter Karman <peter@peknet.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: lucy-dev@lucene.apache.org
CC: "KinoSearch discussion list." <kinosearch@rectangular.com>
Subject: Re: 64-bit linux errors with t/core/032-string_helper.t
References: <4B54BA4F.9010803@peknet.com>
 <20100118234246.GA10083@rectangular.com>
In-Reply-To: <20100118234246.GA10083@rectangular.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Marvin Humphrey wrote on 1/18/10 5:42 PM:
> On Mon, Jan 18, 2010 at 01:45:19PM -0600, Peter Karman wrote:
>> On 64-bit Centos 5 Linux with Perl 5.8.9 I get several failures for 
>> t/core/032-string_helper.t.
>>
>> The issue seems to be related to the u8_t size of the i and max vars. It's 
>> as if they are being evaluated as signed rather than unsigned. However, 
>> even if I hardcode 'unsigned char' instead of the Charmonized 'u8_t' I 
>> still get the same error (below).
>>
>> Changing to an int fixes it. But it doesn't make any sense to me why an 
>> unsigned char wouldn't work.
> 
> I'll bet that what's actually going wrong is the promotion of the arguments
> from "unsigned char" to "long" as they are being passed to ASSERT_INT_EQ.
> 
> To verify, try changing one of the tests from...
> 
>     ASSERT_INT_EQ(batch, StrHelp_UTF8_SKIP[i], 1, 
>         "UTF8_SKIP ascii %d", (int)i);
> 
> ...to:
> 
>     ASSERT_TRUE(batch, StrHelp_UTF8_SKIP[i] == 1, 
>         "UTF8_SKIP ascii %d", (int)i);
> 

alas, that didn't change the output.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com