From 33d523b6274e003bc520d9d0497e24e85de7fae0 Mon Sep 17 00:00:00 2001 From: "jan.nijtmans" Date: Wed, 29 Mar 2017 12:16:28 +0000 Subject: In comments and documentation, distinguish between __int64 (a Microsoft 64-bit integer type) and int64_t (C99 equivalent) --- doc/IntObj.3 | 2 +- generic/tclIO.c | 2 +- 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 ffd2430..64501fd 100644 --- a/generic/tclIO.c +++ b/generic/tclIO.c @@ -9317,7 +9317,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 6da6df3..67b6482 100644 --- a/generic/tclStrToD.c +++ b/generic/tclStrToD.c @@ -3798,7 +3798,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 @@ -3963,7 +3963,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. -- cgit v0.12