|
2009-07-13
| ||
| 01:04 | • Closed ticket [2637173fff]: impure bytearray bugs plus 7 other changes artifact: 29cb96daed user: dkf | |
|
2009-02-26
| ||
| 03:02 | • Ticket [2637173fff]: 4 changes artifact: 7bba9a21bc user: dgp | |
|
2009-02-25
| ||
| 22:39 | • Ticket [2637173fff]: 4 changes artifact: 66ce810a6d user: ferrieux | |
| 22:12 | • Ticket [2637173fff]: 4 changes artifact: 256a7b5924 user: dgp | |
| 14:38 | • New ticket [2637173fff]. artifact: fa0245460f user: dgp | |
| Ticket UUID: | 2637173 | |||
| Title: | impure bytearray bugs | |||
| Type: | Bug | Version: | obsolete: 8.6b1.1 | |
| Submitter: | dgp | Created on: | 2009-02-25 14:38:46 | |
| Subsystem: | 10. Objects | Assigned To: | dkf | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2009-07-13 01:04:44 | |
| Resolution: | Fixed | Closed By: | dkf | |
| Closed on: | 2009-07-12 18:04:44 | |||
| Description: |
When adding some recent optimizations for the tclByteArrayType, it was noted that the stringRep -> byteArray mapping is not one-to-one, so operations that are defined on the stringRep cannot be safely optimized into operations on the byteArray when a stringRep exists. That is, many bytearray optimizations are limited to pure bytearray values. The same issue arises in several routines that have long been optimizing the bytearray case. They all need an audit, and likely bug fixes: StringIndexCmd() StringEqualCmd() StringCmpCmd() TclStringMatchObj() INST_STR_CMP INST_STR_INDEX INST_STR_MATCH | |||
| User Comments: |
dkf added on 2009-07-13 01:04:44:
allow_comments - 1 All fixed now. dgp added on 2009-02-26 03:02:03: fixed only TclStringMatchObj() and only on HEAD ferrieux added on 2009-02-25 22:39:52: Wow ! Indeed we have 7(?) potential bugs here :-) What about promoting the IS_PURE_BYTE_ARRAY from tclStringObj.c to a central header ? Also, please note that TIP 346 attacks this very problem at 180 degrees. dgp added on 2009-02-25 22:12:00: On older branch(es) see also: StringRangeCmd() | |||