Version 8 of 64-bit computing

Updated 2008-09-10 14:00:24 by suchenwi

"Tcl is mostly in good shape for 64-bit platforms. The 'mostly' comes because anyone wanting any individual entity larger than 2GB (which is still a definitely humongous string!) will be in trouble. There is a major piece of clean-up still required to fix that (it's bug 219196, and as you can see it's been known about for a long long time), but I'm planning to put that off until Tcl 9.0 because it is totally incompatible with preceding API versions at the binary level on 64-bit platforms (might also require source changes, but it's the binary-level stuff that's the problem)."

(Quote is from dkf on comp.lang.tcl)

DKF: The remaining major issue is Tcl bug #219196[L1 ]. As you can tell from the number and a little knowledge of SF, we've known about that particular fault/misfeature for a good few years now.

AMG finds "it's been known about for a long long time" to be a horrible, horrible pun.

jcw - bug #219196 is titled "size_t != unsigned int". That could perhaps be resolved by changing the relevant "int" uses to "intptr_t" in the Tcl codebase (intptr_t is an int, guaranteed to be large enough to hold a pointer). The intptr_t typedef is defined in "stdint.h" or "unistd.h".

AMG: But DKF says his concern is with binary compatibility.

LV: And this change is SO incompatible that even at the move from 8.4 to 8.5 we can't make it? 64 bit computing is here now - with Oracle 10 now defaulting to 64 bit libraries, people are going to be able to retrieve huge values from databases, so this is going to be a growing concern to people.


RS 2008-09-10: Are there binary downloads for 64-bit Windows XP available?


[ Category Internals ]