| 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() | |||
Home
Timeline
Branches
Tags
Tickets
Download
Wiki