Tcl Source Code

lset is supposed to only allow setting of elements for out of bounds indices when the specified index is just after the last valid index (i.e. equal to list length). However consider

% set L {}
% lset L 0x7ffffffffffffffe X
index "0x7ffffffffffffffe" out of range
% lset L 0x7fffffffffffffff X
X
% lset L 0x7fffffffffffffff X
index "0x7fffffffffffffff" out of range

When the list is empty, the index 0x7fffffffffffffff (or higher) is incorrectly treated as index 0 (i.e. just beyond last valid index). As the first line shows, smaller out of bounds indices are treated correctly. As the last line shows, this bug only occurs when the list is empty.

Like bug bc076f4f0e, this bug was also introduced by commit 0b05b5c750df intended to fix TIP 577 issues in Tk.

While this issue may be considered relatively minor, it points to what I think is a fundamental flaw in internal index encoding in Tcl: the number of values that need to be represented in an "index" are greater than the range of the index type, no matter whether 32- or 64-bits. This is due to non-negative integers being valid (for obvious reasons), negative integers being valid (as end-N) representation, which together occupy the entire domain. Then there is a need for additional values representing "end" and "one beyond end" for which there is no room necessitating hacks like this which is the cause of the above bug. Removing that hack will cause lset to fail on

set L {} ; lset L 0 X

which should be allowed. Changing the core indexing routines to fix this breaks Tk indexing for negative (in the C API) and end relative indices.

Given the above limitation in range of values I see no way around this other than living with the above bug for 9.0. If I am wrong and anyone has a solution, please verify it works with both Tk and the bigdata tests for large indices.