Generates wrong hashes on PPC

[GoogleCodeExporter]

Quoting an email I got:
==============

I tested this using the "breakdance.avi" file which is given as an example in 
the documentation on 
how to compute the hash values ( 
http://trac.opensubtitles.org/projects/opensubtitles/wiki/HashSourceCodes ). I 
opened 
"breakdance.avi" in Undertext and then used the option "Show Result in Browser" 
in the right 
click menu. This opened the following URL in my browser:

http://www.opensubtitles.org/search/moviebytesize-12909756/moviehash-2e7a4746f2e
59094

Note that the hash value is "2e7a4746f2e59094" while the documentation says it 
should be 
"8e245d9679d31e12".

And a follow up:
==============

The tests which I've done so far worked, though I've only done a few so there 
may still be a bug. 
I've also only done tests on my PowerPC-based Mac, so I'm not sure whether it 
works on an Intel-
based one, though I think it will.

The implementation is in Objective-C. If you're interested in taking a look at 
it, you can find the 
code in the SVN on Sourceforge (link below). The relevant method is 
computeMPCHHashFromFork: in the class RWWorker.

http://galton.svn.sourceforge.net/viewvc/galton/Galton/Classes/RWWorker.m?view=l
og

The code uses the Endian* functions (or macros) provided by Apple to ensure 
independence of 
the endianness of the Mac's CPU. I suspect the problem with the implementation 
in Undertext is 
that it assumes the Mac's CPU is little endian.

Tasks:
==============
 * probably bc of endianness
 * "breakdance.avi" hash works on Intel. Verify to be sure!
 * take a look at code in RWWorker's computeMPCHHashFromFork:
 * check if Ruby-code can be fixed as well

Original issue reported on code.google.com by johanlu...@gmail.com on 27 Apr 2010 at 4:19

[GoogleCodeExporter]

Confirmed that the bug has to do with endianness. "breakdance.avi" hashing 
works in Undertext on Intel. I managed to get the 
code to generate the (faulty) hash "2e7a4746f2e59094" as well. A call to 
#reverse needs to be added like this:

f.read(CHUNK_SIZE).reverse.unpack("Q*").each { |n| ... }

Even though the Ruby docs doesn't say so explicitly, I'm pretty sure the 
Q-directive above always means little-endian byte 
order.

Some resources:
 * http://www.ruby-forum.com/topic/82241
 * http://www.codeproject.com/KB/cpp/endianness.aspx
 * http://beej.us/guide/bgnet/output/html/multipage/htonsman.html

Original comment by johanlu...@gmail.com on 27 Apr 2010 at 11:52

• Changed state: Started

[GoogleCodeExporter]

Commited probable fix in r189. For details read the commit message and diff 
with code comments. Tested on 
my Intel and it generates both correct and faulty hashes. Faulty hashes are 
produced by inverting result of 
endianness check, like this:

BIG_ENDIAN = [1].pack("s") != [1].pack("n")

Fix needs to be verified by testing this on PPC. Please download 
"Undertext-1.2.189-prerelease.dmg" on 
http://code.google.com/p/undertext/downloads/list.

Original comment by johanlu...@gmail.com on 28 Apr 2010 at 9:39

• Changed state: Fixed

[GoogleCodeExporter]

I'll add the file here instead.

Original comment by johanlu...@gmail.com on 28 Apr 2010 at 9:42

Attachments:

• Undertext-1.2.189-prerelease.dmg

[GoogleCodeExporter]

Has been tested on PPC and it's working.

Original comment by johanlu...@gmail.com on 28 Apr 2010 at 9:23