[Tcl-bugs] [ tcl-Patches-2107634 ] extend maximum command length to maxint

[SourceForge.net <no...@so...>]

Patches item #2107634, was opened at 2008-09-12 15:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=2107634&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: 45. Parsing and Eval
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sean Morrison (brlcad)
Assigned to: miguel sofer (msofer)
Summary: extend maximum command length to maxint

Initial Comment:
We ran into a problem in BRL-CAD with the maximum command length in Tcl and have a fix that extends the maximum command limit approximately two times where it presently fails.  The provided patch pushes that limit up about 2x by checking for the overflow and clamping to maxint.  If that maxint limit is exceeded, then it now returns -1 instead of crashing too.

The current behavior without the patch is that 'length' ends up overflowing causing a crash inside Tcl_SetObjLength() where it tries to use length (which is negative maxint) as an array index.

For those wondering just how we'd actually blow out that limit, our (.asc) ASCII file format in BRL-CAD is essentially a Tcl transcript.  So to load a file, we just have Tcl parse the file.  Being a CAD package, our files are geometry.  One of the geometry types is a polygonal mesh... So when you have one mesh that is really big (which is really easy to do), you end up blowing out the command length.

This fix should be credited to Bob Parker (BRL-CAD developer) if it is applied.  The patch was made against 8.5.1

We fully admit that the patch isn't ideal, but it does resolve the problem from our standpoint without any negative consequences until the API can be improved.  As you're undoubtedly well-aware, DoReadChars() and friends need to not use int everywhere for string/buffer length tracking, instead using size_t's or something similarly longer (and fixed) instead of int.

Cheers!
Sean



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=2107634&group_id=10894