Skip Menu |

This queue is for tickets about the Tk CPAN distribution.

Report information
The Basics
Id: 16595
Status: open
Priority: 0/
Queue: Tk

People
Owner: NI-S [...] cpan.org
Requestors: coyote.frank [...] gmx.net
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 804.027
Fixed in: (no value)



Subject: Bug in encGlue.c:CallEncode causes TCL_Panic
System: Tk800_027, perl5.8.7, Debian Sarge, KDE While tracking back a TCL_Panic when deleting a large selection in a TK::Text (see http://groups.google.com/group/comp.lang.perl.tk/browse_thread/thread/af1150eec445ccdf) I stumbled over the following code in encGlue.c. 677 quiet = get_sv("Tk::encodeFallback",0); ... 723 PUSHMARK(sp); 724 XPUSHs(PerlEncObj(encoding)); 725 XPUSHs(stmp); 726 XPUSHs(quiet); 727 PUTBACK; 728 perl_call_method(method,G_SCALAR|G_EVAL); ... 745 if (SvCUR(stmp)) 746 { 747 /* This could also be TCL_CONVERT_MULTIBYTE - how do we tell ? */ 748 code = TCL_CONVERT_UNKNOWN; 749 break; 750 } If I understand this right this would call $encoding->encode( $string, 0 ) unless Tk:encodeFallback is set and expect it to delete the encodes chars from string or fail with TCL_CONVERT_UNKNOWN (check in line 745) which will cause the TCL_Panic later in my case. $encoding is a Encode::Encoding object (Encode::utf8 in my case) and reading the Encode::Encoding manpage it says | ->encode($string [,$check]) | MUST return the octet sequence representing $string. | | * If $check is true, it SHOULD modify $string in place to remove | the converted part (i.e. the whole string unless there is an | error). If perlio_ok() is true, SHOULD becomes MUST. | | * If an error occurs, it SHOULD return the octet sequence for the | fragment of string that has been converted and modify $string in- | place to remove the converted part leaving it starting with the | problem fragment. If perlio_ok() is true, SHOULD becomes MUST. | | * If $check is is false then "encode" MUST make a "best effort" to | convert the string - for example, by using a replacement charac- | ter. So there is no description what should happen with $string in case $check is 0 false and conversion was OK. In fact Encode::utf8->encode( $string,0 ) just returns the converting string and leaves $string unchanged. Thus the test in line 745 will fail even if everything was correct. If I set $Tk::encodeFallback to true everything is fine, no panic occurs.
RT-Send-CC: dankogai [...] dan.co.jp
I closed 16596 and 16597 which seemed to be identical? I think your analysis is correct. Although I wrote the original Encode module (for perl/Tk) it has since been taken over and generalized a bit and API has changed - the way check argument works in particular. As I recall a number of people were upset that the source string was modified. Because Encode was in a state of flux when Tk was released the idea of the C code you quoted is that $Tk::encodeFallback is passed as the check argument. This is initialized as (in my copy): ./Tk.pm:23: $Tk::encodeFallback = Encode::FB_PERLQQ(); So the problem should be fixable by a patch to just the perl code and a workround should be to set $Tk::encodeFallback = ...; in your code, to something that works with your perl/Encode. So now we are left studying the various incarnations of Encode and deciding which is the best value for Tk to use. It does not help that various different encodings treated value of check rather differently. The perlio flag was added as encoding layers (which were also mine originally) assume(d) encodings work like I originally intended them to rather than how they did work at the time. So it may be that setting $Tk::encodeFallback to perlio mode will suffice. I have Cc:ed the current Encode maintainer.