[TCLCORE] Re: 64 bit numbers on IA32

[Don B. <do...@pi...>]

FYI I am looking at improving the 64-bit support in TCL.
Specifically I am looking at making 64-bit integers work
regardless of whether the machine is 32 or 64 bit.
(ie using __int64 / long long).

I need some opinions.

The simplest way to do that is simply to raise the size
of the value in a Tcl_Obj. This doesn't change the size of
a Tcl_Obj, its already got the space. However, there's
an issue with binary compatibility because things like
Tcl_ExprLong, Tcl_NewIntObj, etc now would have
a pointer to a wider type. I've got this all prototyped,
I created a new type, Tcl_IntegerType, and throughout
made references use only this type.
(* There's actually a lot of changes, strtoul, strtol,
all the explicit casts to (int), (long), (void *), etc).

This would work for compiling new extensions with the
tcl.h, C rules would apply for promotion to larger values
(sign extending and so on) so the extensions could be
rebuilt without trouble.

However, there's a break to binary compatibility.

Another way to do this is to define a set of new API,
and deprecate the old ones, but keep them at the current
size (32-bits in most cases).

This means there would be:
Tcl_NewIntObj,
Tcl_NewLongObj,
Tcl_New???Obj

This is quite a bit more work, and extensions and so on
need to be reworked if they wish to get access to larger precision
types.

My personal preference is the first approach, Tcl_NewIntObj should
be used to create a new integer, and that shouldn't need to specify the
size. When compiled as 64-bit, an integer would be 64-bits throughout
tcl. This is also the least prone to creating bugs.

However, I don't want to go through and do all the work if the patches
won't be accepted.

If you have an opinion, please email me as do...@pi....

Thanks very much.

--don

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.