"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)."

DKF: The remaining major issue is Tcl bug #219196[1]. 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".

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.

DKF: I know it's a problem. It's why I think we need to do Tcl 9 sooner rather later. But it's only an issue if you're actually working with a string (or list or other structure) that is really large; with a BLOB or CLOB it's probably better to treat it as a channel or something like that so you don't deal with that massive lump all at once. That's what JDBC does for example.

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