From: SourceForge.net <no...@so...> - 2009-09-01 08:27:48
|
Bugs item #2848176, was opened at 2009-09-01 04:31 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2848176&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 48. Number Handling Group: current: 8.5.7 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Karl C. Hansen (kchansen) Assigned to: Don Porter (dgp) Summary: Invalid results from "expr", v8.4.*, v8.5.*, v8.6.* Initial Comment: Both crc16.tcl and crc32.tcl use a variable named "signmask", that is constructed from another variable named "signbit". For 32-bit data, signbit is 0x8000000. For 32-bit CRCs, the signmask appears to be designed to mask off the high-byte, i.e. it should end up 0x00ffffff. Signmask is computed as follows: set signmask [expr {~$signbit>>7}] Printing $signbit shows the expected value of 0x80000000: % puts $signbit 0x80000000 But if we print the bit-complement of this (which in 32-bit land we expect to be positive) we get: % expr ~$signbit -2147483649 When we format this using "format 0x%x" we oddly get: % format 0x%x [expr ~$signbit] 0x7fffffff Even worse, the above calculations for signmask now no longer give 0x00FFFFFF, but rather 0xFEFFFFFF, which is pretty much guaranteed to give the wrong result. It looks like the number is kind of living in both "long-land" and 32-bit-land. In long-land the 0x80000000 gets sign-extended from 32-bit-land, and after that the bit-complement would indeed be still negative. But the format statement seems to think the number is 32-bit-land-only.... Help! ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2009-09-01 09:27 Message: It'd help a lot if you could let us know which crc*.tcl scripts have this problem. (The issue is probably that the code therein is not 64-bit safe, and so would have actually been a problem on some platforms even before 8.4. Though those platforms were much less common back then.) ---------------------------------------------------------------------- Comment By: Karl C. Hansen (kchansen) Date: 2009-09-01 04:33 Message: Because this deals with math and breaks some existing code (crc-32 calculations) I am hoping my assigning the highest priority will stick.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2848176&group_id=10894 |