[Bill Tutt] > After making use of the test drive Alphas by Compaq, I just > uploaded a patch to SF that should fix this nasty issue. > Ugh. Not fun.... Ah, I replied earlier before seeing this. Please see my earlier response for a simpler change that will actually work <wink>. Briefly, > > len = cch; > > p = (unsigned char *) key; > > - x = 1694245428; > > + x = (long)0x64fc2234; No point to this change (although there *is* for the *negative* literal in f2). And (for f2) note that the way to spell a long literal is with "L" at the end, not via casting an int literal to long. > > while (--len >= 0) > > - x = (1000003*x) ^ toupper(*(p++)); > > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); No point to either of the changes here (you're effectively doing a mod 2**32 on each step, but that isn't necessary -- doing just one at the end (after the loop) is equivalent). > > x ^= cch + 10; > > - if (x == -1) > > - x = -2; > > + if (x == (long)0xFFFFFFFF) > > + x = (long)0xfffffffe; This is wrong in too many ways to count <wink>. But your tests won't show the failure unless x *does* happen to equal -1 at the end of the preceding, and you're extremely unlikely to bump into that in a small batch of test cases. Short course: on the 32-bit long machine, x will be -2 after this block then. But on the 64-bit long machine, x will be 2**32-2 (a large and unrelated positive long). The change I suggested is simpler & avoids all those problems; alas, like the above, it also assumes 2's-complement representation of negative longs.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4