In Tcl releases 8.5.0 through 8.5.7, the public header file `tcl.h`
contains the typedef:

===
typedef unsigned long mp_digit;
===

Starting in Tcl 8.5.8, this is changed to:

===
typedef unsigned int mp_digit;
===

The purpose of this page is to discuss what incompatibilities
this may introduce for C code that uses the Tcl public interface,
and how to manage them.

----

First, note that on many (32-bit) systems, `long` and `int` are
just two names for the same thing.  If your C code is only ever
compiled on such systems, the change is not really a change at all,
and you have no compatibility issues to worry about.

For C code that does get compiled for L64 systems, read on...

----

The set of public Tcl routines that are affected by this change can
only be called from a compilation unit that includes the
header file `tclTomMath.h` in addition to `tcl.h`.  For
those C source files that do not include the `tclTomMath.h`
header, there can be no incompatibility in how the Tcl
public interface is used introduced by this change.

Having eliminated that possibility, the only remaining thing to 
check is whether you have your own C code that for some reason
contains expressions that operate on variables
of type `mp_digit`.  If that is the case, you will need to
examine what impact this change has for builds on LP64 systems.
Since that situation is unlikely, and has nothing to do with
calls into Tcl public routines, we'll say no more about it here.

----

Compilation units that include `tclTomMath.h` are presumed to
be calling one of the routines declared by it.  If your C code
calls any of the routines:

====
  mp_add_d()
  mp_cmp_d()
  mp_div_d()
  mp_expt_d()
  mp_init_set()
  mp_mul_d()
  mp_set()
  mp_sub_d()
====

Then your code '''does have''' a binary and stubs incompatibility
with Tcl at the 8.5.7 -> 8.5.8 patch release transition.  The
declarations of the routines above give one or more arguments
the type ''mp_digit'' or ''(mp_digit *)'', and the change in
size of this type on LP64 systems means that binary code produced
assuming one size will be incompatible with binary code produced
assuming the other size.
----