| Ticket UUID: | be003d570f6d392e02644e25f84d1cd82082bf0a | |||
| Title: | scan 0x40 %o | |||
| Type: | Bug | Version: | 8.5+ | |
| Submitter: | dgp | Created on: | 2016-10-11 18:33:50 | |
| Subsystem: | 23. [scan] | Assigned To: | dgp | |
| Priority: | 5 Medium | Severity: | Minor | |
| Status: | Closed | Last Modified: | 2016-10-12 14:03:17 | |
| Resolution: | Fixed | Closed By: | dgp | |
| Closed on: | 2016-10-12 14:03:17 | |||
| Description: |
Somewhere along the way we botched this: % scan 0x40 %o 64 | |||
| User Comments: |
dgp added on 2016-10-12 14:03:17:
Fix on all branches. dgp added on 2016-10-12 14:02:50: [scan 0x40 %b] was also broken in 8.6+ dgp added on 2016-10-12 13:18:10: Patches coming. dgp added on 2016-10-12 13:17:39: [scan 0x40 %x] => 64 is the correct result. ferrieux added on 2016-10-12 00:09:44: Yes, it looks like %o has implied TCL_SCAN_PREFIXES since the TIP implementation. I assume there was some deep reason ; kbk might remember it ? Note that [scan 0x40 %x] also wrongly returns 64, but by a different mechanism: %x only sets parseFlag to TCL_PARSE_HEXADECIMAL_ONLY, but then morphs the opcode into 'i'; the code for 'i' subsequently uses (parseFlag | TCL_SCAN_PREFIXES), which is the intended semantics for %i. So the %x variant is rather a consequence of "optimistic refactoring"... dgp added on 2016-10-11 19:47:12: TIP 237 | |||
View Ticket