[Top][All Lists]
[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
- [Gnash] non-portable amf test?,
Petter Reinholdtsen <=