Inconsistent handling of binary strings (Windows vs. Linux)

Paul Obermeier

unread,

Aug 21, 2022, 1:31:36 PM8/21/22

to

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

Schelte

unread,

Aug 21, 2022, 2:41:27 PM8/21/22

to

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.

apn

unread,

Aug 21, 2022, 2:47:17 PM8/21/22

to

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

Paul Obermeier

unread,

Aug 21, 2022, 3:57:54 PM8/21/22

to

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

Robert Heller

unread,

Aug 21, 2022, 4:00:51 PM8/21/22

to

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
hel...@deepsoft.com -- Webhosting Services

Paul Obermeier

unread,

Aug 21, 2022, 4:01:39 PM8/21/22

to

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

Ralf Fassel

unread,

Aug 22, 2022, 4:53:49 AM8/22/22

to

* Paul Obermeier <ober...@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'