Tcl Source Code

View Ticket
Login
Ticket UUID: 8d1fc70995703e6727591d7179833a4a1970d6a5
Title: lseq "count" error persists across calls
Type: Bug Created on: 2026-01-13 19:25:55
Submitter: tomkiti Assigned to: griffin
Subsystem: 17. Commands I-L Severity: Minor
Priority: 5 Medium Last modified: 2026-03-09 07:39:30
Status: Closed Closed by: jan.nijtmans
Resolution: Fixed Closed on: 2026-03-09 07:39:30
Version: 9.0.3
Description:
If an lseq "count" command returns an error, the command returns an error forever:

% lseq 0 count 5
0 1 2 3 4

% lseq count 5
invalid bareword "count"
in expression "count";
should be "$count" or "{count}" or "count(...)" or ...

% lseq 0 count 5
invalid bareword "count"
in expression "count";
should be "$count" or "{count}" or "count(...)" or ...
User Comments:
apnadkarni added on 2026-01-14 11:57:53:

What platform is this (though I doubt that would make a difference). I could not reproduce this in 9.0.0, 9.0.2, 9.0.3 and trunk (9.1) on Windows.

% info pat
9.0.3
% lseq 0 count 5
0 1 2 3 4
% lseq count 5
invalid bareword "count"
in expression "count";
should be "$count" or "{count}" or "count(...)" or ...
% lseq 0 count 5
0 1 2 3 4

juliannoble2 added on 2026-01-14 13:32:26:
curious..
I see the persistent error as reported.

Tested:
windows 10 
  9.0b3 9.0.2 and 9.0.3
windows 11 25H2 
  9.0.2

The 9.0.3 is a recent download of the magicsplat distribution, the 9.0b3 is also magicsplat

The 9.0.2 is bawt

I don't see it in an obsolete 8.7 I have on the windows 10 machine.

apnadkarni added on 2026-01-14 14:52:50:

Ok, found the difference. I have history turned off in my tclshrc. Re-enabling it reproduces the error.

It also means (I suspect) the error would not occur in a script (including the test suite!) since history is disabled in that situation.

In any case, I confirm that it's a real bug that needs investigating.


griffin added on 2026-01-14 16:18:38:

Thank you for this report!

Even without the unexpected interaction with the user's environment, the use of lseq key words in positions of numeric arguments, should be checked by the command, and provide a more meaningful error message.


apnadkarni added on 2026-01-14 17:30:50:

And in fact, the error can be reproduced in a script as well. The argument just has to have a reference count > 1.

x.tcl:

set count count
puts [catch {lseq 0 $count 5} result],$result
puts [catch {lseq $count 5} result],$result
puts [catch {lseq 0 $count 5} result],$result

Running it,

c:\src\tcltk\wip\tcl\win>tclsh x.tcl
0,0 1 2 3 4
1,invalid bareword "count"
in expression "count";
should be "$count" or "{count}" or "count(...)" or ...
1,invalid bareword "count"
in expression "count";
should be "$count" or "{count}" or "count(...)" or ...

apnadkarni added on 2026-01-14 17:38:46:

I think the optimization in function SequenceIdentifyArgument is broken

	if (TclHasInternalRep(argPtr, &tclExprCodeType)) {
	   goto doExpr;
	}

Basing a decision on the current internal representation type feels like it violates EIAS. Here for example, "count" is an invalid expression but still has bytecode representing it generated (which will raise an error). "count" passed as the third argument though is not to be treated as an integer but a keyword. The above fragment means that treatment of "count" depends on what the last type it was shimmered to which feels like a violation of EIAS.


jan.nijtmans added on 2026-03-09 07:39:30:

Since the fix branch is now merged to bothe 9.0 and trunk, this can be closed.

Thanks!