Tcl Source Code

On 64bit system, the following code returns an unexpected result.


(On Linux 32bit machine)
% lsearch -sorted -integer [lsort -integer {0 2147483648}] 2147483648
0
=> the value was found


(On Linux 64bit machine)
% lsearch -sorted -integer [lsort -integer {0 2147483648}] 2147483648
-1
=> the value was not found

Dup of [3216010]. Fix already committed, so closing.

Upgrade to Tcl_WideInt part now committed to trunk [f70fa16889]. I don't have any objections backporting this to core-8-5-branch, or enhance it further to work for bignums as well. Therefore keeping this open.

I agree with Donald that as first-fix the data-type could be up-scaled, but I would go one little step further: use Tcl_WideInt in both commands. See branch "bug-47d66253c9".

That would resolve a related strange result (reproduced on win32):

% lsearch -sorted -integer [lsort -integer {0 -2147483648}] 2147483648
0

2 % lsearch -sorted -integer [lsort -integer {0 2147483648}] -2147483648
0

Agreed? I don't see any unexpected side-effects from such a change.

However, a minimal first fix would be to switch to using a long and get rid of a little bit of the difference between 32-bit and 64-bit.

At least it's not something which is exposed in an API.

I'm tempted to say that the meaning of “-integer” that a reasonable user would expect would correspond to “anything that satisfies string is entier -strict”; limiting to signed-platform-word is… surprising.

What this ticket seems to demonstrate, though,
is that the meaning of "-integer" is inconsistent
between [lsort] and [lsearch].  I confirm that.
[lsort] uses Tcl_GetLongFromObj() and [lsearch]
uses Tcl_GetIntFromObj(), so on systems where
int and long are different (64-bit systems),
they are inconsistent.

That's an unfortunate mess.  Whether it's a bug,
and if so whether fixing it would solve more problems
or create more new ones, I'll have to discuss with
others.

This is all a symptom of the messy stew of integer
treatment in Tcl that history has delivered to us.
See TIP 297.

[lsort -integer] is not portable.  The interpretation
it places on values varies with value of
$tcl_platform(wordSize).  For the same reason, you see:

(On 32-bit system)
% expr int(2147483648)
-2147483648

(On 64-bit system)
% expr int(2147483648)
2147483648