| Ticket UUID: | 1770224 | |||
| Title: | TclGetNumberFromObj caller must save result | |||
| Type: | Bug | Version: | obsolete: 8.5a7 | |
| Submitter: | dgp | Created on: | 2007-08-08 18:57:44 | |
| Subsystem: | 47. Bytecode Compiler | Assigned To: | dgp | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2007-08-09 03:25:04 | |
| Resolution: | Fixed | Closed By: | dgp | |
| Closed on: | 2007-08-08 20:25:04 | |||
| Description: |
For example: % >> -0x8000000000000001 0x8000000000000000 0 Result should be -1. [>> $big $wide] is ok: % >> -0x8000000000000001 0x7fffffffffffffff -1 And clearly, shifting that -1 one more bit ought to return -1 again, not 0. Perhaps a clue... it's not always broken: % >> -0x8000000000000000 0x8000000000000000 -1 | |||
| User Comments: |
dgp added on 2007-08-09 03:25:04:
Logged In: YES user_id=80530 Originator: YES committed. dgp added on 2007-08-09 03:21:05: File Added - 240469: 1770224.patch Logged In: YES user_id=80530 Originator: YES Ok, problem did not show up elsewhere. Here's the patch. File Added: 1770224.patch dgp added on 2007-08-09 02:35:22: Logged In: YES user_id=80530 Originator: YES ok, problem is that when TclGetNumberFromObj() returns a bignum, it uses some temp space. The caller is supposed to save the result before calling again. The >> implementation code is not doing so, so when both arguments are bignums, we end up doing the operation with the second argument twice. This not only points the way to fixing this bug; it points out a whole project of code review to be done. Ick. dgp added on 2007-08-09 02:07:41: Logged In: YES user_id=80530 Originator: YES ok that last "not broken" example actually fits in a wide. | |||
Attachments:
- 1770224.patch [download] added by dgp on 2007-08-09 03:21:04. [details]