Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Mon, 18 Jan 2010 15:42:46 -0800
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
Message-ID: <20100118234246.GA10083@rectangular.com>
References: <4B54BA4F.9010803@peknet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B54BA4F.9010803@peknet.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Marvin Humphrey <marvin@rectangular.com>

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);

If that's indeed the problem, I'd prefer not to fix it that way, as it will
cut down on the usefulness of verbose test output and make smoke test reports
harder to analyze.  Instead, we should add the following:

    TEST_I8_EQUALS
    TEST_U8_EQUALS
    TEST_I16_EQUALS
    TEST_U16_EQUALS
    TEST_I32_EQUALS
    TEST_U32_EQUALS
    TEST_I64_EQUALS
    TEST_U64_EQUALS

That's easier now that we're no longer using Charmonizer's test suite.

The choice of "TEST_*" rather than "ASSERT_*" is driven by the fact that
unlike typical xUnit tests, these return false on failure rather than throw
exceptions.

Marvin Humphrey