format() under TCL v. 8.4

[rbn]

Hi folks,

I have a question regarding TCL's format() command under TCL v. 8.4.
Below I've made two examples. test1.tcl uses format(), test2.tcl uses
expr() to set b. Both use $a by value (not by reference). However, it
seems that format() alters the representation of $a, so that it gets
sign-extended to 64 bits, whereas the use of expr() doesn't. I would
had expected that test1.tcl executed with v. 8.4 yielded "pos", as is
the case with test2.tcl.

Is this a bug in format() under v. 8.4 or is there a logical
explanation?

Thx in advance.

/René Bøje Nielsen

test1.tcl:
set a 0xdeadbeef
set b [format %u $a]
if {$a < 0} {puts neg} else {puts pos}

test2.tcl:
set a 0xdeadbeef
set b [expr $a + 1]
if {$a < 0} {puts neg} else {puts pos}

Results:

tclsh8.3 test1.tcl:
neg

tclsh8.3 test2.tcl:
neg

tclsh8.4 test1.tcl:
neg ;# WOULD HAVE EXPECTED "pos"

tclsh8.4 test2.tcl:
pos

Patchlevels:
tclsh8.3: 8.3.4
tclsh8.4: 8.4.7
Executed under Linux on both 32- and 64-bit boxes with same results.

[tom.rmadilo]

Before you do the test, why not 'puts $a;puts $b' to see what the
actual values are. Remember that comparisons are not necessarily
numeric or base 10, 16 or 8, you need many more examples to actually
tell what is happening (just having a leading zero could mess things
up).

I did a bunch of tests for 'decimal' values as compared to 'string is
integer', I'm not sure how much code is shared for type detection, but
lots of testing for this helps to make your code robust to this issue.

http://junom.com/ws/decimal.tcl

[Larry W. Virden]

On Aug 27, 11:53 am, rbn <r...@optisoft.cc> wrote:

> Is this a bug in format() under v. 8.4 or is there a logical
> explanation?

> Results:

>
> tclsh8.3 test1.tcl:
> neg
>
> tclsh8.3 test2.tcl:
> neg
>
> tclsh8.4 test1.tcl:
> neg ;# WOULD HAVE EXPECTED "pos"
>
> tclsh8.4 test2.tcl:
> pos

tclsh8.5 test1.tcl:
pos
tclsh8.5 test2.tcl:
pos

Patchlevel 8.5a7

Executed in 64 bit mode on SPARC Solaris.

[Andreas Leitgeb]

rbn <r...@optisoft.cc> wrote:

Code:

> set a 0xdeadbeef
> set b [format %u $a]
> if {$a < 0} {puts neg} else {puts pos}

Result:

> neg ;# WOULD HAVE EXPECTED "pos"

Could be a bug in 8.4.7 (that appears to
be fixed in 8.4.12, which I've got here)

Code:

> set a 0xdeadbeef
> set b [expr $a + 1]
> if {$a < 0} {puts neg} else {puts pos}

Result:
> pos

The expr command you put here, surely doesn't have any effect
on a, because $a is used as string (which it already was),
then combined to a larger string "0xdeadbeef + 1". Only
that is then parsed by expr. any reverse-connection to $a
is lost by then.

Perhaps you meant "[expr {$a + 1}]", which might have some
"shimmering" effect on $a. This shimmering effect once
became even visible at tcl-level, but I think that bug
is long fixed by now.