summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--doc/IntObj.32
-rw-r--r--generic/tclIO.c2
-rw-r--r--generic/tclStrToD.c4
3 files changed, 4 insertions, 4 deletions
diff --git a/doc/IntObj.3 b/doc/IntObj.3
index dc62642..2acb446 100644
--- a/doc/IntObj.3
+++ b/doc/IntObj.3
@@ -97,7 +97,7 @@ are provided by the C language standard. The \fBTcl_WideInt\fR type is a
typedef defined to be whatever signed integral type covers at least the
64-bit integer range (-9223372036854775808 to 9223372036854775807). Depending
on the platform and the C compiler, the actual type might be
-\fBlong int\fR, \fBlong long int\fR, \fBint64\fR, or something else.
+\fBlong int\fR, \fBlong long int\fR, \fB__int64\fR, or something else.
The \fBmp_int\fR type is a multiple-precision integer type defined
by the LibTomMath multiple-precision integer library.
.PP
diff --git a/generic/tclIO.c b/generic/tclIO.c
index 6bf8451..a509ebf 100644
--- a/generic/tclIO.c
+++ b/generic/tclIO.c
@@ -9276,7 +9276,7 @@ MBWrite(
* then the calculations involving extra must be made wide too.
*
* Noted with Win32/MSVC debug build treating the warning (possible of
- * data in int64 to int conversion) as error.
+ * data in __int64 to int conversion) as error.
*/
bufPtr = AllocChannelBuffer(extra);
diff --git a/generic/tclStrToD.c b/generic/tclStrToD.c
index 224ab45..c7fdc5a 100644
--- a/generic/tclStrToD.c
+++ b/generic/tclStrToD.c
@@ -3805,7 +3805,7 @@ ShorteningBignumConversion(
--s5;
/*
- * IDEA: It might possibly be a win to fall back to int64
+ * IDEA: It might possibly be a win to fall back to int64_t
* arithmetic here if S < 2**64/10. But it's a win only for
* a fairly narrow range of magnitudes so perhaps not worth
* bothering. We already know that we shorten the
@@ -3970,7 +3970,7 @@ StrictBignumConversion(
* As with the shortening bignum conversion, it's possible at this
* point that we will have reduced the denominator to less than
* 2**64/10, at which point it would be possible to fall back to
- * to int64 arithmetic. But the potential payoff is tremendously
+ * to int64_t arithmetic. But the potential payoff is tremendously
* less - unless we're working in F format - because we know that
* three groups of digits will always suffice for %#.17e, the
* longest format that doesn't introduce empty precision.