gnash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash] non-portable amf test?


From: Petter Reinholdtsen
Subject: [Gnash] non-portable amf test?
Date: Fri, 25 May 2007 10:47:33 +0200
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (usg-unix-v)

I see from <URL:http://bugs.debian.org/425616> that several amf tests
fail on linux/s390.  I had a look at the code in
testsuite/libamf.all/test_number.cpp, and it include this code
(removed unused parts):

    AMF amf_obj;
    int fd, ret;
    char buf[AMF_NUMBER_SIZE+1];
    amfnum_t *num;

    memset(buf, 0, AMF_NUMBER_SIZE+1);
    string filespec = SRCDIR;
    filespec += "/f03f.amf";
    fd = open(filespec.c_str(), O_RDONLY);
    ret = read(fd, buf, AMF_NUMBER_SIZE);
    close(fd);

    num = amf_obj.extractNumber(buf);
    if ((((char *)num)[6] == -16) && (((char *)num)[7] == 0x3f)) {
        runtest.pass("Extracted Number AMF object");
    } else {
        runtest.fail("Extracted Number AMF object");
    }

The test fail on s390, as it would on all architectures with a
different endianness than the authors machine.

Why is the test written like that?  The amfnum_t type is a 64 bit
integer type, and I would thus expect it to make more sense to just do
'if (*num == 0xf03fL)'.  Why isn't it done like that?

This test isn't the only failing one, bug I have not investigated the
rest.

Friendly,
-- 
Petter Reinholdtsen





reply via email to

[Prev in Thread] Current Thread [Next in Thread]