Tcl Source Code

% lseq 0x7fffffffffffffff count 2
9223372036854775807 -9223372036854775808

The above should raise an error instead.

Now when we build with -ftrapv (one of the configurations used on the trunk) we get an abort on line 762 of tclArithSeries.c during test lseq-bug-0ee626dfb2-0:

	    end = start + (step * (len - 1));

(Technically it's in code called from that line due to how trapping arithmetic is implemented on this platform, but that's the line at fault.)

On the other hand, I can't see anywhere where end (or its trivial derivative, dend, computed on the next line) is used at all after that point in that function. Deleting the whole innermost branch containing that failing location makes the test pass.

@griffin

I still have discomfort with the return of an empty list under conditions where we should generate errors. For example,

% llength [lseq -0x8000000000000000 to -1 by 1]
0

which is clearly wrong. Since Tcl cannot handle counts that large, it should generate an error, not return a bogus result.

Also, with regards to step size of 0, consider

% lseq 42 to 42 by 0
%

The return value I would expect is {42}, not an empty string. But the documentation states a step size of 0 will return an empty list so behaves as documented. Still unexpected in my opinion and should be changed. Conversely, if start != end, a step size of 0 is an infinite series of "start" and not an empty sequence. Given Tcl cannot represent that, again an error should be raised. If we fix the former and not the latter, we have inconsistency like

[llength [lseq 42 to 42 by 0]] > [llength [lseq 42 to 43 by 0]]

If you disagree with the above and no one else has a problem with the current behavior, I'll leave it as it is.

The empty error message seems to have been fixed already.

I would like to add the following additional checks:

• a negative count argument should generate an error, not return an empty list.

• a step size of 0 should generate an error if the passed length is greater than 1 and not return an empty list.

Comments?

Along the same lines (I think same root cause),

% lseq 0x7fffffffffffffff count 3 by -0x7fffffffffffffff
9223372036854775807 0 -9223372036854775807
% lseq 0x7fffffffffffffff count 3 by -0x8000000000000000
9223372036854775807 -1 9223372036854775807

The first line above is correct, the second is not.

Proposed fix on branch [bug-0ee626dfb2].

Also, not related but recording as a reminder to be fixed.

% catch {lseq -0x7f .. 0x7f count 2} message
1
% set message
% set errorCode
NONE

Above correctly generates a (syntax) error but with an empty error message.