本文提出了一种新的类型long long，这是一种保证至少具有 64 位精度的整数类型。这遵循了编译器供应商建立的广泛的事实上的标准，因为在客户要求大型整数类型时，他们宁愿扩展语言而不是更改现有类型的大小。

一、引言

大型数据库、大型文件系统和对象请求代理系统都需要大型整数。C9X 应该通过提供一种保证至少具有 64 位精度的整数类型来满足这一需求。

乍一看，这似乎可以通过要求long至少具有 64 位精度来轻松实现。然而，如果 C9X 标准这样做，将迫使供应商破坏客户的代码；不仅是遵循 32 位 long 整数广泛假设的不可移植代码，还包括任何使用预编译库和二进制格式数据的代码。这样的标准可能会遭到相当一部分供应商和用户的抵制。

供应商在引入一个全新的系统（所有软件都将是全新的，并且共享相同的数据大小）时，在基本数据类型的大小选择上有很大的自由度，但在现有系统上更改基本数据类型的大小或表示方式会产生广泛的后果。

考虑一下当客户在一个刚刚将long从 32 位更改为 64 位的实现上修改和重新编译应用程序时会发生什么。原始二进制数据文件会损坏。可能更重要的是，对使用旧实现编译的库的调用会中断（库源文件指出，对某个特定函数的参数是一个long，在旧实现中是 32 位，因此库对象文件中的函数期望接收一个 32 位类型；应用程序包含的库头文件也指出，对同一函数的参数是long，现在是 64 位，因此应用程序传递的是一个 64 位类型）。

其结果是，客户无法在不重新编译（如果有源代码）或获取重新编译版本（如果没有源代码）的情况下修改应用程序，而这些应用程序使用的所有库都必须更改。所有内容都必须同时更改；没有平缓的过渡。出于这个原因，许多系统供应商选择避免更改基本整数类型的大小，而是将long long建立为事实上的标准。

C9X 应该遵循供应商的做法，并引入long long作为一种新的基本整数类型，其保证的最小精度为 64 位。