| Ticket UUID: | 506297 | |||
| Title: | Problems writing iso2022-jp | |||
| Type: | Bug | Version: | obsolete: 8.3.3 | |
| Submitter: | ruric | Created on: | 2002-01-21 05:46:15 | |
| Subsystem: | 24. Channel Commands | Assigned To: | andreas_kupries | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2002-01-22 03:38:49 | |
| Resolution: | Fixed | Closed By: | andreas_kupries | |
| Closed on: | 2002-01-21 20:38:49 | |||
| Description: |
This happens on tcl8.3.4 (also tested on 8.3.3) on Linux. I have a channel open for writing with encoding iso2022-jp. When I "puts" a certain string tcl gets stuck in a loop and the output file starts growing indefinitely. The problem can be demonstrated by the following script: set string [format %s%c [string repeat " " 4094] 12399] set f [open out w 0644] fconfigure $f -encoding iso2022-jp puts -nonewline $f $string close $f This script will, when executed, never get past teh puts statement and the outfile will start to grow (fast:-). The problem lies in WriteChars in tclIO.c. When Tcl_UtfToExternal is called with TCL_ENCODING_START set among the flags, then it will always generate at least three bytes (assuming the output encoding is iso2022-jp). However it did not consume any of the characters in the input buffer (at least not if TCL_ENCODING_END is clear). But the logic in WriteChars thinks that since it generated output we shoudl call it again... The attached patch fixes this by removing the TCL_ENCODING_START bit from flags after the first call to Tcl_UtfToExternal. | |||
| User Comments: |
andreas_kupries added on 2002-01-22 03:38:49:
Logged In: YES user_id=75003 Committed to head and core-8-3-1-branch. andreas_kupries added on 2002-01-22 03:36:39: File Added - 16497: 506297-84.diff andreas_kupries added on 2002-01-22 03:36:04: File Added - 16496: 506297-834.diff Logged In: YES user_id=75003 Enclosing the official patches. Additional comments in the code explaining the problem and the fix. Additional test in the testsuite to check for this problem. andreas_kupries added on 2002-01-22 02:52:38: Logged In: YES user_id=75003 * Confirmed behaviour for 8.3.4 and 8.4cvs After the fix an outfile of size 4105 bytes is generated. Checksumming: [andreask@pliers 84]$ cksum out 1762614785 4105 out [andreask@pliers 84]$ md5sum out b14544da022231b9116e2c4ca1acb7c5 out andreas_kupries added on 2002-01-21 13:14:39: Logged In: YES user_id=75003 Yep. I closed the others already. I will take this as the main report, simply because here the submitter is not Nobody/Anonymous :) ruric added on 2002-01-21 12:57:07: Logged In: YES user_id=433503 OOPS, it seems as sourceforge actually inserted this into the bug-database even through it gave men an error. At least that applies to the earlier three copies now in there(:-(). So currently there are four reports for this bug: 506189 506292 506296 and this one ruric added on 2002-01-21 12:46:16: File Added - 16459: patch | |||
Home
Timeline
Branches
Tags
Tickets
Download
Wiki