Tcl Source Code

Ticket Change Details
Login
Overview

Artifact ID: b43674f7e7c11e69c63ddc8e1b41e27562e833ea
Ticket: 3598590fffffffffffffffffffffffffffffffff
UpdateStringOfList should use TclConvertElement length
User & Date: dkf 2013-11-12 12:39:32
Changes

  1. closedate changed to: "2456609.02745837"
  2. closer changed to: "dkf"
  3. comment changed to:
    tclListObj.c:UpdateStringOfList (which is what I'm cloning for an extension), loops TclScanElement to estimate size of buffer. It then sets Tcl_Obj.length as this estimate. As per source comments for TclScanElement this number is a *over*estimate and it is the lengths returned from TclConverElement that should be used. The only way it works as is if TclScanElement always returns a exact count, never an over estimate I can't actually get it to return an overestimate (yet) Either TclScanElement docs are wrong or the code needs to be fixed to use the lengths returned by TclConvertElement Yes, highly unlikely USOL does not work! But I think it is more likely the estimate is precise than the overallocation being harmless else you would get trailing garbage in some cases, I think (both the length field and the terminating null point to the end of allocated space) Other possibility is that the overestimate is some really arcane case that is not in the tests and will rarely (never?) occur in real life It appears as though the extra space happens (afaict) only when the CONVERT_ANY flag is passed in to TclScanElement. 
    
    Since UpdateStringOfList does not pass this flag, it appears to be safe.  However, to keep to the documented TclScanElement interface and guard against future changes, I think it should use the lengths returned by TclConvertElement instead.
    
  4. login: "dkf"
  5. mimetype: "text/plain"
  6. severity changed to: "Minor"
  7. status changed to: "Closed"