diff options
| -rw-r--r-- | doc/IntObj.3 | 2 | ||||
| -rw-r--r-- | generic/tclIO.c | 2 | ||||
| -rw-r--r-- | generic/tclStrToD.c | 4 |
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. |