Tcl Source Code

This is a follow-up report to #219314. While the patch 
for that report possibly fixes the problem for the 
particular strings used it does not solve the general 
problem exposed by the test script in that report.

The general problem is this:

When using an escape encoding as the system encoding 
where will come a time when the escape encoding has to 
load one of the subordinate encodings to perform its 
task. At that time the system will try to translate 
the filename for that subordinate encoding using the 
current system encoding. Which is partially loaded, we 
have to load a subordinate encoding. The filename for 
that has to be translated ... Ad infinitum. Or at 
least until stack or heap run out.

Jeff proposes the following general solution:

When the command [encoding system] detects that the 
users asked it to make an escape encoding the system 
encoding it preloads all subordinate encodings 
*before* installing the escape encoding as the new 
system encoding. This prevents any future attempts to 
load the subordinate encodings. The penalty is that 
loading the system encoding takes more time in this 
case.

allow_comments - 1

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

The difference between branches when
a subencoding of an escape encoding is missing
persists.  In 8.4.* the missing encoding is noticed
when we try to first load the escape encoding and
an error is thrown.  In 8.5+ we carry on, and later
if that missing subencoding is actually needed
during encoding operations and it remains missing,
Tcl will panic.

The original bug (infinite loop loading an escape encoding)
is long fixed.  This ticket had hi priority as a signal to
discover what it was in the revised encoding system of 8.5 that
killed performance on Windows when patched.  That was
never determined.  Unknown whether it is even still true.

Either branch's approach to this vanishingly rare event
seems defensible.  Plan to just leave things alone.

Logged In: YES 
user_id=80530
Originator: NO


I lost track of this one.

Is this still buggy on the HEAD?
Is the patch still an effective,
but performance-killing-on-Windows
fix there?

Logged In: YES 
user_id=80530


Based on testing reports, the
latest patch was good for
8.4.13, but kills performance
on Windows somehow on 8.5a4.

Reverted from the HEAD.

Logged In: YES 
user_id=80530


committed for 8.4.13 and 8.5a4

File Added - 92565: 506653.patch

Logged In: YES 
user_id=80530


It appears to me that
Patch 689341(committed in
February 2003) has for the
most part fixed this bug.
Since it was applied, the
loading of an escape encoding
causes all of its subencodings
to be loaded first.

The only issue that appears
to be unresolved is handling
the case where one or more
of the subencodings is missing.
The attached patch fills that hole.

Please review and apply if
acceptable.