From: <no...@so...> - 2002-02-24 02:51:38
|
Bugs item #440916, was opened at 2001-07-12 20:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=440916&group_id=10894 Category: 48. Portability Support Group: 8.4a3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Don Porter (dgp) >Assigned to: Daniel A. Steffen (das) Summary: compat/strtoul.c fails tests Initial Comment: 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 '-'. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2002-02-23 18:51 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-02-23 15:31 Message: Logged In: YES user_id=80530 Note: I'm working up a patch that appears to solve all problems. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-02-23 14:36 Message: 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 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-02-23 14:20 Message: 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. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-22 23:00 Message: Logged In: YES user_id=72656 can this be reverified on the latest sources following dkf's latest set of patches? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-09-05 13:29 Message: 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? ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2001-09-04 17:26 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-09-04 16:36 Message: 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. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2001-09-01 01:27 Message: 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. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2001-08-31 18:33 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-07-12 22:28 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-07-12 20:55 Message: Logged In: YES user_id=80530 Here's the patch. Assigning to maintainer for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=440916&group_id=10894 |