Tcl Source Code

 
When I force libtcl to include the strtoul() routine 
from compat/strtoul.c, the following tests in the 
test suite fail: 

scan-4.38
scan-4.39
scan-5.6

This is because strtoul() fails to handle leading
sign symbols '+' and '-'.

File Added - 18313: strto.patch

Logged In: YES 
user_id=80530

Here's a patch that combines the best parts of all
patches attached already, and fixes a few more things
in the compat/strto*.c files to boot.

Committing it now; Dan Steffen should check that it
doesn't break anything on the Mac.

Logged In: YES 
user_id=80530

Note: I'm working up a patch that appears to solve
all problems.

Logged In: YES 
user_id=80530

Applying the first patch attached to this report
fixes all but two of the failures:

format-17.1
string-6.55

Logged In: YES 
user_id=80530

Things are .... different now.

First let's just consider good old 32-bit Solaris.
With current CVS HEAD sources (unpatched), if you
force compat/strtoul.c to be compiled into Tcl, the
resulting library has these test failures.

==== format-17.1 testing %d with wide FAILED
==== Contents of test case:

    list [catch {format %d 7810179016327718216} msg] $msg

---- Result was:
0 1819043144
---- Result should have been (exact matching):
1 {integer value too large to represent}
==== format-17.1 FAILED

==== lindex-4.2 index = end--1 FAILED
==== Contents of test case:

    set x end--1
    list [eval [list $lindex {a b c} $x]] [eval [list
$lindex {a b c} $x]]

---- Result was:
bad index "end--1": must be integer or end?-integer?
---- Result should have been (exact matching):
{} {}
---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
==== lindex-4.2 FAILED


==== lindex-12.2 index = end--1 FAILED
==== Contents of test case:

    set x end--1
    catch {
        list [lindex {a b c} $x] [lindex {a b c} $x]
    } result
    set result

---- Result was:
bad index "end--1": must be integer or end?-integer?
---- Result should have been (exact matching):
{} {}
==== lindex-12.2 FAILED

==== lset-4.5 lset, not compiled, 3 args, index out of range
FAILED
==== Contents of test case:

    set a {x y z}
    list [catch {
        eval [list $lset a [list end--1] w]
    } msg] $msg

---- Result was:
1 {bad index "end--1": must be integer or end?-integer?}
---- Result should have been (exact matching):
1 {list index out of range}
==== lset-4.5 FAILED


==== lset-4.11 lset, not compiled, 3 args, index out of
range FAILED
==== Contents of test case:

    set a {x y z}
    list [catch {
        eval [list $lset a end--1 w]
    } msg] $msg

---- Result was:
1 {bad index "end--1": must be integer or end?-integer?}
---- Result should have been (exact matching):
1 {list index out of range}
==== lset-4.11 FAILED


==== lset-8.9 lset, not compiled, second index out of range
FAILED
==== Contents of test case:

    set a {{b c} {d e} {f g}}
    list [catch {eval [list $lset a 2 end--1 h]} msg] $msg

---- Result was:
1 {bad index "end--1": must be integer or end?-integer?}
---- Result should have been (exact matching):
1 {list index out of range}
==== lset-8.9 FAILED


==== lset-8.10 lset, not compiled, second index out of range
FAILED
==== Contents of test case:

    set a {{b c} {d e} {f g}}
    list [catch {eval [list $lset a {2 end--1} h]} msg] $msg

---- Result was:
1 {bad index "end--1": must be integer or end?-integer?}
---- Result should have been (exact matching):
1 {list index out of range}
==== lset-8.10 FAILED

==== obj-31.3 regenerate string rep of "end--1" FAILED====
Contents of test case:

    testobj freeallvars
    teststringobj set 1 end--0x1
    testobj convert 1 end-offset
    testobj invalidateStringRep 1

---- Result was:
expected integer but got "--0x1"
---- Result should have been (exact matching):
end--1
---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
==== obj-31.3 FAILED

==== obj-31.5 regenerate string rep of "end--bigInteger" FAILED
==== Contents of test case:

    testobj freeallvars
    teststringobj set 1 end--0x7fffffff
    testobj convert 1 end-offset
    testobj invalidateStringRep 1

---- Result was:
expected integer but got "--0x7fffffff"
---- Result should have been (exact matching):
end--2147483647
---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
==== obj-31.5 FAILED
==== scan-4.38 Tcl_ScanObjCmd, base-8 integer scanning FAILED
==== Contents of test case:

    set x {}
    list [scan {+1238 -1239 123a} {%o%*s%o%*s%o} x y z] $x $y $z

---- Result was:
3 0 0 83
---- Result should have been (exact matching):
3 83 -83 83
==== scan-4.38 FAILED

==== scan-4.39 Tcl_ScanObjCmd, base-16 integer scanning FAILED
==== Contents of test case:

    set x {}
    list [scan {+1238 -123a 0123} {%x%x%x} x y z] $x $y $z

---- Result was:
3 0 0 291
---- Result should have been (exact matching):
3 4664 -4666 291
==== scan-4.39 FAILED

==== scan-5.6 integer scanning FAILED
==== Contents of test case:

    set a {}; set b {}; set c {}; set d {}
    list [scan "ab123-24642" "%2x %3x %3o %2o" a b c d] $a
$b $c $d

---- Result was:
4 171 291 0 52
---- Result should have been (exact matching):
4 171 291 -20 52
==== scan-5.6 FAILED

==== string-6.55 string is integer, false on overflow FAILED
==== Contents of test case:

    list [string is integer -fail var +[largest_int]0] $var

---- Result was:
1 3
---- Result should have been (exact matching):
0 -1
==== string-6.55 FAILED

Things are event more broken on the Alpha, but
let's get the simple case fixed first.

Logged In: YES 
user_id=72656

can this be reverified on the latest sources following 
dkf's latest set of patches?

Logged In: YES 
user_id=80530

The strtol() in the latest patch is broken on 64-bit Alpha.
This starts to touch on the 64-bit int handling issues
also under examination elsewhere.

If possible, I'd like to limit this patch to fixing the
bugs in the strtoul() routine in compat/strtoul.c and
not confront those other issues.

What sort of "incompatibilities" did you see on the
Mac when replacing only the strtoul() routine in the
internals of Tcl?

Logged In: YES 
user_id=90580

Ah yes, thanks, I forgot to mention that, the strtol() in 
strtol.c has the same problems w.r.t to error reporting (i.e. 
there is none), moreover when adding error reporting to 
strtol one can't call strtoul anymore as the information 
necessary to determine strtol error conditions isn't passed 
back...
which is why I put them both into the same file and call a 
common private_strtoul() function. So indeed compat/strtoul.c 
can go away.

There is no reason for the leading __ to private_strtoul, 
you're correct it's better to leave them off; sorry about 
that. The only reason they are there is that the code I 
looked at for guidance had something similar...

Thanks for looking into the const issues.

Logged In: YES 
user_id=80530

The latest patch puts an implementation of strtol()
in the file compat/strtoul.c .  Does that mean the
file compat/strtol.c is no longer needed?

The private internal helper routine __private_strtoul
begins with two "_"'s.  Seems to me that treads on some
reserved territory, at least with some compilers (?).
Why not leave off the leading __ ?  It's a static
function so we shouldn't need to worry about conflicts,
right?

There are also some CONST issues that need fixing too.
I'm working on that, but please comment on these other
points.

File Added - 10241: strtoul-2.patch

Logged In: YES 
user_id=90580

It appears the earlier patch didn't get attached properly, 
here is a new version:

The Metrowerks implementations of strtoul, strtol, atoi and 
atol are all using the same underlying code, so by just 
replacing the standard library strtoul by compat/strtoul.c I 
was getting inconsistencies between uses of strtoul and 
strtol etc.

The updated patch has implementations of all these routines 
now, based on the earlier strtoul patch

strtol, atoi and atol may need to be #ifdef MAC_TCL 'd out if 
they cause problems on other systems, please review.

All tests pass on mac with this patch.

Logged In: YES 
user_id=90580

on the mac, string-6.37 fails because of missing error 
checking in compat/strtoul.c, the attached updated patch adds 
appropriate overflow checking.

With the updated strtoul.c all test now pass on mac.

File Deleted - 8376: 



File Added - 8377: strtoul.patch

Logged In: YES 
user_id=80530

When both compat/strtoul.c and compat/strtol.c are
linked in, test scan-4.42 fails because strtoul()
fails to recognize "0X" as a valid hex prefix.

The updated patch corrects this problem as well.

File Added - 8376: strtoul.patch

Logged In: YES 
user_id=80530


Here's the patch.  Assigning to maintainer for review.