Tk Library Source Code

See bug 631314 for some past history of this.

The error termination is annoying me, and the pre-631314 code would avoid it, except that in some cases it causes an infinite loop.

This seems to be because the older code changes the value of line, without changing the value stored for its length (in the meaningfully-named variable x). the following patch seems to deal with this, avoiding both the error and the infinite loop:

*** 832,839 ****
      while {$moreP} {
          if {$fileP} {
              if {$pos > $last} {
!                  error "termination string missing in $state(content)"
                   set line "--$boundary--"
              } else {
                if {[set x [gets $state(fd) line]] < 0} {
                    error "end-of-file encountered while parsing $state(content)"
--- 832,840 ----
      while {$moreP} {
          if {$fileP} {
              if {$pos > $last} {
!                  # error "termination string missing in $state(content)"
                   set line "--$boundary--"
+                set x [string length line]
              } else {
                if {[set x [gets $state(fd) line]] < 0} {
                    error "end-of-file encountered while parsing $state(content)"

Logged In: YES 
user_id=75003
Originator: NO

Accepted my updated patch. CVS head is now mime 1.5.4.

File Added - 277826: mime-1961881-a.patch

Logged In: YES 
user_id=75003
Originator: NO

Updated the patch in my sandbox.
Moved handling of missing starting boundary around.
Added forcing to app/octstream and handled possibility that part is broken beyond parsability.

File Added: mime-1961881-a.patch

Logged In: YES 
user_id=75003
Originator: NO

The 'meaningful' variable 'x' comes from (IIRC), i.e. blame me. Should be 'linelength' or some such.

2007-11-05  Andreas Kupries  <[email protected]>

* mime.tcl (::mime::parsepart): Fixed [SF Tcllib Bug 1825092],
* mime.test: as reported by Max Strobel
* pkgIndex.tcl: <[email protected]>. The code parsing
* mime.man: multiparts assumed that eol sequences are always two
  characters (cr+lf), this however may not be the case. This
  caused the parser to miscount the last line in a part and
  wrongly remove its last character from the part. Extended the
  testsuite, and bumped the version to 1.5.3.

Attaching the patch I have sitting in my sandbox. I am not fully satisfied with it. While it avoids the loop some of the commentary in 631314 seems to indicate that I should also munge the mime-type of the new part, i.e. force application/octet-stream, whatever the headers claimed for it.

The necessary updates to the testsuite are missing as well, however that it is more or less a formality.

Logged In: YES 
user_id=75003
Originator: NO

Meh. Retracting my statement. The mime-3.7 test case is bad in itself. mime-3.8 is a testcase for the same problem and doesn't run into the infinite loop with patch applied. In mime-3.7 the 'badmail1.txt' the given boundary is the terminating boundary, however it is not recognized because the parser newer saw an initial boundary. The patch now faking a terminating boundary cannot help there, its fake boundary will not be recognized either, hence the infinite loop.

I think I may try to fake a bit more, i.e. set inP as if we had seen an initial boundary.

Logged In: YES 
user_id=75003
Originator: NO

I am not able to confirm that. With the patch applied the testcase mime-3.7 in mime.test hangs and strategic output reveals that it is stuck in the infinite loop you wish to avoid.

What operating system are you on ?
Maybe that makes the difference between your non-loop and my oo-loop.
I tried this on Linux.