When running the following simple script, I get different outputs depending on Tcl version and operating system.
Can anyone confirm?
Is it a bug or feature?

Paul


# Linux 8.6.12: 12345678900 -> 12345678900 -> 0XFFFFFFFFDFDC1C34
# Linux 8.7.a5: 12345678900 -> 12345678900 -> 0XFFFFFFFFDFDC1C34
# Windows 8.6.12: -539222988 -> -539222988 -> 0XDFDC1C34
# Windows 8.7.a5: 12345678900 -> -539222988 -> 0XDFDC1C34

set num [expr int(12345678900)]
set bin [binary format i $num]
binary scan $bin i ret
puts "$num -> [format %d $num] -> [format 0X%X $ret]"
exit 0

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

With respect to the *platform* differences for the *same* version, I'll
term it a feature as it is documented. The docs for int() map it to tcl_platform(wordSize) which in turn maps to the C sizeof(long) which is
32 bits on Windows and 64 bits on Linux.

For 8.7, I would claim it is a bug for the simple reason that it does
not stay compatible with 8.6. No idea whether the change is intended or not.

/Ashok

On 8/21/2022 11:01 PM, Paul Obermeier wrote:

When running the following simple script, I get different outputs
depending on Tcl version and operating system.
Can anyone confirm?
Is it a bug or feature?

Paul

# Linux   8.6.12: 12345678900 -> 12345678900 -> 0XFFFFFFFFDFDC1C34
# Linux   8.7.a5: 12345678900 -> 12345678900 -> 0XFFFFFFFFDFDC1C34
# Windows 8.6.12:  -539222988 -> -539222988  -> 0XDFDC1C34
# Windows 8.7.a5: 12345678900 -> -539222988  -> 0XDFDC1C34

set num [expr int(12345678900)]
set bin [binary format i $num]
binary scan $bin i ret
puts "$num -> [format %d $num] -> [format 0X%X $ret]"
exit 0

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/08/2022 19:31, Paul Obermeier wrote:

When running the following simple script, I get different outputs
depending on Tcl version and operating system.
Can anyone confirm?
Is it a bug or feature?

The differences you see seem mostly attributable to a 64-bit tclsh
(linux) vs 32-bit tclsh (windows). They are not related to binary
strings at all. In all cases the binary scan returns -539222988. But
printing a negative number in hex with 64-bits produces 16 characters,
while you only get 8 characters when using 32-bits.

The other difference between 8.6 and 8.7 on a 32-bit tclsh are due to
TIP 514. Before TIP 514, the int() function would cut the number to the
native integer size. With your 32-bit tclsh on windows, that produces a negative number. On the 64-bit tclsh on linux, enough bits are available
to represent the full number. After TIP514, no truncation takes place at
all anymore.


Schelte.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 21.08.2022 um 20:41 schrieb Schelte:

On 21/08/2022 19:31, Paul Obermeier wrote:

When running the following simple script, I get different outputs depending on Tcl version and operating system.
Can anyone confirm?
Is it a bug or feature?

The differences you see seem mostly attributable to a 64-bit tclsh (linux) vs 32-bit tclsh (windows). They are not related to binary strings at all. In all cases the binary scan returns -539222988. But printing a negative number in hex with 64-bits

produces 16 characters, while you only get 8 characters when using 32-bits.

The other difference between 8.6 and 8.7 on a 32-bit tclsh are due to TIP 514. Before TIP 514, the int() function would cut the number to the native integer size. With your 32-bit tclsh on windows, that produces a negative number. On the 64-bit tclsh

on linux, enough bits are available to represent the full number. After TIP514, no truncation takes place at all anymore.

Schelte.

All Tcl versions are 64-bit, but as Ashok explains in the next thread, the wordsize is different on Windows and Linux.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

At Sun, 21 Aug 2022 20:41:20 +0200 Schelte <nospam@wanadoo.nl> wrote:

On 21/08/2022 19:31, Paul Obermeier wrote:

When running the following simple script, I get different outputs
depending on Tcl version and operating system.
Can anyone confirm?
Is it a bug or feature?

The differences you see seem mostly attributable to a 64-bit tclsh
(linux) vs 32-bit tclsh (windows). They are not related to binary
strings at all. In all cases the binary scan returns -539222988. But
printing a negative number in hex with 64-bits produces 16 characters,
while you only get 8 characters when using 32-bits.

The other difference between 8.6 and 8.7 on a 32-bit tclsh are due to
TIP 514. Before TIP 514, the int() function would cut the number to the native integer size. With your 32-bit tclsh on windows, that produces a negative number. On the 64-bit tclsh on linux, enough bits are available
to represent the full number. After TIP514, no truncation takes place at
all anymore.

Just did a test using Wine64 and a 64-bit MS-Windows tclkit. It behaves the same as a 32-bit MS-Windows (same as the OP).

Also, running a 32-bit (ix86) Linux exe on a 64-bit Linux box also produces a the -539222988 decimal and 8 character hex result.

Both 8.6.11.

I don't know if there is a real problem with the 64-bit MS-Windows build, or
if it is a "feature"...

Schelte.

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks Ashok for clarification, although the different results on Windows and Linux is not a behaviour I expect from a platform-independent scripting language.

Am 21.08.2022 um 20:47 schrieb apn:

With respect to the *platform* differences for the *same* version, I'll term it a feature as it is documented. The docs for int() map it to tcl_platform(wordSize) which in turn maps to the C sizeof(long) which is 32 bits on Windows and 64 bits on Linux.

For 8.7, I would claim it is a bug for the simple reason that it does not stay compatible with 8.6. No idea whether the change is intended or not.

/Ashok

On 8/21/2022 11:01 PM, Paul Obermeier wrote:

When running the following simple script, I get different outputs depending on Tcl version and operating system.
Can anyone confirm?
Is it a bug or feature?

Paul


# Linux   8.6.12: 12345678900 -> 12345678900 -> 0XFFFFFFFFDFDC1C34
# Linux   8.7.a5: 12345678900 -> 12345678900 -> 0XFFFFFFFFDFDC1C34
# Windows 8.6.12:  -539222988 -> -539222988  -> 0XDFDC1C34
# Windows 8.7.a5: 12345678900 -> -539222988  -> 0XDFDC1C34

set num [expr int(12345678900)]
set bin [binary format i $num]
binary scan $bin i ret
puts "$num -> [format %d $num] -> [format 0X%X $ret]"
exit 0

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Paul Obermeier <obermeier@poSoft.de>
| Thanks Ashok for clarification, although the different results on
| Windows and Linux is not a behaviour I expect from a
| platform-independent scripting language.

First I wanted to agree with you here.
But thinking again, the behaviour of internal integer handling is
documented (and the same on all platforms), and the behaviour of ::tcl::mathfunc::int is documented too (as being platform dependend),
I'd say if you need int > 2GB for sure, use wide() instead of int().

R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)