From: SourceForge.net <no...@so...> - 2009-02-25 15:40:04
|
Bugs item #2637173, was opened at 2009-02-25 15:38 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2637173&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: 10. Objects Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Porter (dgp) Assigned to: Donal K. Fellows (dkf) Summary: impure bytearray bugs Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-02-25 16:39 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2009-02-25 16:12 Message: On older branch(es) see also: StringRangeCmd() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2637173&group_id=10894 |