openGL规范（glspec45.core.pdf）定义了所有GL...类型的确切位宽度：
2.2.1状态设定命令的数据转换
...
实施必须精确使用 表中指示的位代表GL类型。
...
但所谓的OpenGL注册表（GL.XML-官方可泊OpenGL API规范）天真地将这些类型定义为对相应C类型的别名。
...
<type>typedef short <name>GLshort</name>;</type>
<type>typedef int <name>GLint</name>;</type>
<type>typedef int <name>GLclampx</name>;</type>
...
它可能是不安全的。
为什么不使用固定宽度类型？
为什么没有预处理器逻辑来确定正确的类型？为什么没有类型大小的编译时间检查？
，更重要的是，在制作OpenGL功能/扩展程序加载程序时，我应该如何定义这些类型？
它可能是不安全的。
是的，是。
所以？
只要不是实际上不安全，只要您不尝试在不提供这些类型的预期尺寸的奇数平台/编译器上运行此代码，没关系。它适用于GCC，Clang，VC 以及几乎所有其他主要编译器。这些定义在Windows，MacOS，Linux，Android，iOS和许多其他系统上都可以使用。
我了解更强烈遵守C和C 标准的愿望。但是现实是，这些定义对于大多数使用的真实系统都可以。对于它们不正确的系统，该系统的单个OpenGL提供商可以为这些系统提供替代定义。
为什么不使用固定宽度类型？
因为在此类类型之前就存在
。请记住：它们可以追溯到C99/C 11；OpenGL可以追溯到1992年。
为什么没有类型大小的编译时间检查？
早在1992年，C 甚至不是标准化。那时可能存在什么"编译时间检查"？此外，OpenGL是根据C的定义，C的编译时间计算能力主要由极端宏观编程技术组成。
，更重要的是，在制作OpenGL功能/扩展程序加载程序时，我应该如何定义这些类型？
除非您有特定的需要否则要做，否则正如gl.xml所说的定义它们一样。
我知道这个问题已经回答，但是我想在glew.h文件中添加某些OpenGL类型在有条件地定义，具体取决于编译器版本或操作系统。
例如：
#if defined(_MSC_VER) && _MSC_VER < 1400
typedef __int64 GLint64EXT;
typedef unsigned __int64 GLuint64EXT;
#elif defined(_MSC_VER) || defined(__BORLANDC__)
typedef signed long long GLint64EXT;
typedef unsigned long long GLuint64EXT;
#else
# if defined(__MINGW32__) || defined(__CYGWIN__)
#include <inttypes.h>
# endif
typedef int64_t GLint64EXT;
typedef uint64_t GLuint64EXT;
#endif