If you run queueext test, it fails at test090.

% r queueext
.
.Test090: queueext ( -extent 2  -len 20 -pad 0 ) 1000 equal key/data pairs
	Starting at 4294967000
	Test090.a: put/get loop
FAIL:13:42:55 (00:00:00) run_method: queueext 90: integer value too large to
represent as non-long integer

Here's the real problem in tcl-8.3.3:
tcl8.3.3/tests 305 bash$ tclsh scan.test

==== scan-4.62 scanning of large and negative octal integers FAILED
==== Contents of test case:

    foreach { MIN_INT MAX_INT } [int_range] {}
    set scanstring [format {%o %o %o} -1 $MIN_INT $MAX_INT]
    list [scan $scanstring {%o %o %o} a b c]  [expr { $a == -1 }] [expr { $b ==
$MIN_INT }] [expr { $c == $MAX_INT }]

==== Test generated error:
integer value too large to represent as non-long integer
---- Result should have been:
3 1 1 1
==== scan-4.62 FAILED


==== scan-4.63 scanning of large and negative hex integers FAILED
==== Contents of test case:

    foreach { MIN_INT MAX_INT } [int_range] {}
    set scanstring [format {%x %x %x} -1 $MIN_INT $MAX_INT]
    list [scan $scanstring {%x %x %x} a b c]  [expr { $a == -1 }] [expr { $b ==
$MIN_INT }] [expr { $c == $MAX_INT }]

==== Test generated error:
integer value too large to represent as non-long integer
---- Result should have been:
3 1 1 1
==== scan-4.63 FAILED

scan.test:	Total	162	Passed	159	Skipped	1	Failed	2
Number of tests skipped for each constraint:
	1	nonPortable

And here's the check (from tcl8.3.3/generic/tclObj.c:1596)
...
    l = objPtr->internalRep.longValue;
    if (((long)((int)l)) == l) {
        *intPtr = (int)objPtr->internalRep.longValue;
        return TCL_OK;
    }
    if (interp != NULL) {
        Tcl_ResetResult(interp);
        Tcl_AppendToObj(Tcl_GetObjResult(interp),
                "integer value too large to represent as non-long integer",
-1);    }
    return TCL_ERROR;
}


It turns out that all integers are stored within tcl
as longs, but the API passes values as integers.
That means that there are values (i.e. 4294967000)
that cannot be passed into tcl when sizeof(long) > sizeof(int)

This is an intrinsic problem to tcl, not gonna be fixed
better than what's there already, the real problem is ints
wired throughout the API.

Meanwhile substituting -128 (i.e. the signed int32 representation
of 4294967000) will trick tcl into running the db3 test
successfully on alpha, dunno what that does on i386.

Eeek, I forgot to convert from 0x128 to -296.
Analysis is still correct, here's the test results:

db3/db-3.2.9/build_unix 347 bash$ tclsh
% source ../test/test.tcl
% test090 queueext
Test090: queueext ( -extent 2  -len 20 -pad 0 ) 1000 equal key/data pairs
	Starting at -296
	Test090.a: put/get loop
	Test090.b: dump file
	Test090.c: close, open, and dump file
	Test090.d: close, open, and dump file in reverse direction
Test090: queueext ( -extent 2  -len 20 -pad 0 )
	Test090.a: put/get loop
	Test090.b: dump file
	Test090.c: close, open, and dump file
	Test090.d: close, open, and dump file in reverse direction
Test090: queueext ( -extent 2  -len 20 -pad 0 ) Test of DB_WAIT flag to DB->get.
Using -txn environment.
	Starting at -296.
Script watcher process 22468 launching conscript.tcl process 22470.
Script watcher process 22469 launching conscript.tcl process 22471.
Script watcher process 22473 launching conscript.tcl process 22478.
Script watcher process 22475 launching conscript.tcl process 22477.
Script watcher process 22474 launching conscript.tcl process 22479.
Script watcher process 22472 launching conscript.tcl process 22480.
All processes have exited.
	Test090: Verifying results.
	Test090 completed successfully.

I'm not sure that a patch is anything other than cosmetic
however.

Going by Jeff's analysis:

	"That means that there are values (i.e. 4294967000)
	 that cannot be passed into tcl when sizeof(long) > sizeof(int)

	 This is an intrinsic problem to tcl, not gonna be fixed
	 better than what's there already, the real problem is ints
	 wired throughout the API."

This would mean a fundemental rewrite of Tcl's API. Umm.
Not going to happen.

At best this all boils down to a design flaw in Tcl. This really needs the Tcl
people to go off into a back room somewhere and rethink their stratagy for 64bit
archs.

Phil
=--=