summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorjan.nijtmans <nijtmans@users.sourceforge.net>2017-03-29 12:16:28 (GMT)
committerjan.nijtmans <nijtmans@users.sourceforge.net>2017-03-29 12:16:28 (GMT)
commit33d523b6274e003bc520d9d0497e24e85de7fae0 (patch)
tree1b89496b0aa7f00c62593edd50a6a0ad82684689
parentc755d23a508df80984dc1755ea1c96af87f27425 (diff)
downloadtcl-33d523b6274e003bc520d9d0497e24e85de7fae0.zip
tcl-33d523b6274e003bc520d9d0497e24e85de7fae0.tar.gz
tcl-33d523b6274e003bc520d9d0497e24e85de7fae0.tar.bz2
In comments and documentation, distinguish between __int64 (a Microsoft 64-bit integer type) and int64_t (C99 equivalent)
-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 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.