#2291 [string is integer] inconsistency

[Reinhard Max]

Given the following two commands:

string is integer 12345678901
string is integer [expr 12345678901]

On i386 they both return 0, but on x86_64
the second one returns 1.

I think they should return 1 on all platforms
that support wide integers.

[Don Porter]

Logged In: YES
user_id=80530

Note that this bug is present in 8.3.5;
it has nothing to do with wide integers.

For value with only a string rep,
[string is integer] asks "Can this
string be read as a C "int" ?"

For values that already have an integer
internal type, it asks "Does this value
fit in a C "long" ?"

For any platform where sizeof(long) != sizeof(int),
the answers will not be consistent.

Making them consistent is easy, but that
requires knowing which answer is the right
one. The docs do not specify in enough detail.

[Reinhard Max]

Logged In: YES
user_id=124643

Does that mean it would need a TIP to get defined semantics
for [string is integer], and then fix the implementation?

[Don Porter]

Logged In: YES
user_id=80530

committed fix to make [string is integer]
consistently recognize 32-bit integers
(C int's) for both string and internal
representations, and across platforms.
Updated docs and tests.

If we want something to recognize either
64-bit integers consistently, or platform
C longs in a platform-specific manner, we
need a TIP to either change [string is integer],
or provide another command ([string is wide] ?).