当64位int在C/C++中转换为64位浮点数并且没有完全匹配时，它是否总是落在非小数上？

当 int64_t 被强制转换为 double 并且没有完全匹配时，据我所知，我得到了一种等效于 double 的尽力而为最近的值。例如， int64_t 中的 9223372036854775000 似乎在 double 中以 9223372036854774784.0 结尾：

#include <stdio.h>

int main(int argc, const char **argv) {
    printf("Corresponding double: %fn", (double)9223372036854775000LL);
    // Outputs: 9223372036854774784.000000
    return 0;
}

在我看来，似乎 int64_t 转换为 double 总是以干净的非小数结束，即使在 double 精度非常低的较高数字范围内也是如此。但是，我只是从随机尝试中观察到这一点。对于 int64_t 转换为 double 的任何值，是否保证会发生这种情况？

如果我将这个非小数双精度转换回 int64_t，我是否总是能得到精确对应的 64 位 int 并且 .0 被切掉？（假设它在转换回来期间没有溢出。）像这里：

#include <inttypes.h>
#include <stdio.h>

int main(int argc, const char **argv) {
    printf("Corresponding double: %fn", (double)9223372036854775000LL);
    // Outputs: 9223372036854774784.000000
    printf("Corresponding int to corresponding double: %" PRId64 "n",
           (int64_t)((double)9223372036854775000LL));
    // Outputs: 9223372036854774784
    return 0;
}

或者它可能不精确并在某些极端情况下让我得到“错误”的 int ？

凭直觉和我的测试，这两点的答案似乎都是“是”，但是如果对浮点标准及其背后的数学有很好的正式理解的人可以确认这一点，那对我来说真的很有帮助。我也很好奇是否已知任何已知的更激进的优化（例如 gcc 的优化）-Ofast会破坏其中的任何一个。

回答

>>> bin(9223372036854775000)
'0b111111111111111111111111111111111111111111111111111110011011000'
>>> bin(9223372036854774784)
'0b111111111111111111111111111111111111111111111111111110000000000'