OpenGL 规范规定 `GLint` 必须为 32 位宽，但 gl.xml 天真地将其定义为 `int` 而不是 `int32_t`。为什么？
OpenGL spec says that `GLint` must be 32 bits wide, but gl.xml naively defines it as `int` instead of `int32_t`. Why?
OpenGL specification (glspec45.core.pdf) 为所有 GL... 类型定义精确的位宽：
2.2.1 Data Conversion For State-Setting Commands
...
An implementation must use exactly the number of
bits indicated in the table to represent a GL type.
...
但所谓的 OpenGL registry（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 functions/extensions 加载器时，我应该如何定义这些类型？
It is potentially unsafe.
是的，是的。
那么？
只要它实际上不安全，只要你不尝试运行这个代码在一个奇怪的球上platform/compiler不提供这些类型的预期大小，没关系。它适用于 GCC、Clang、VC++ 以及几乎所有其他主要编译器。这些定义适用于 Windows、MacOS、Linux、Android、iOS 以及许多其他系统和 ABI。
我理解强烈遵守 C 和 C++ 标准的愿望。但现实情况是，这些定义适用于大多数实际使用的系统。对于它们不完善的系统，由该系统的各个 OpenGL 提供商为这些提供替代定义。
Why fixed-width types weren't used instead?
因为 OpenGL 在 之前就存在了，所以这些类型存在。请记住：它们的日期是 C99/C++11； OpenGL 可追溯到 1992 年。
Why no compile-time checks of type sizes?
早在 1992 年，C++ 甚至还没有标准化。 "compile-time checks" 那时候可能存在什么？另外，OpenGL是用C定义的，C的编译时计算能力主要是极端的宏编程技术。
And what's more important, when making an OpenGL functions/extensions loader, how should I define those types?
除非你有特定的需要否则，完全按照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
OpenGL specification (glspec45.core.pdf) 为所有 GL... 类型定义精确的位宽：
2.2.1 Data Conversion For State-Setting Commands
...
An implementation must use exactly the number of bits indicated in the table to represent a GL type.
...
但所谓的 OpenGL registry（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 functions/extensions 加载器时，我应该如何定义这些类型？
It is potentially unsafe.
是的，是的。
那么？
只要它实际上不安全，只要你不尝试运行这个代码在一个奇怪的球上platform/compiler不提供这些类型的预期大小，没关系。它适用于 GCC、Clang、VC++ 以及几乎所有其他主要编译器。这些定义适用于 Windows、MacOS、Linux、Android、iOS 以及许多其他系统和 ABI。
我理解强烈遵守 C 和 C++ 标准的愿望。但现实情况是，这些定义适用于大多数实际使用的系统。对于它们不完善的系统，由该系统的各个 OpenGL 提供商为这些提供替代定义。
Why fixed-width types weren't used instead?
因为 OpenGL 在 之前就存在了，所以这些类型存在。请记住：它们的日期是 C99/C++11； OpenGL 可追溯到 1992 年。
Why no compile-time checks of type sizes?
早在 1992 年，C++ 甚至还没有标准化。 "compile-time checks" 那时候可能存在什么？另外，OpenGL是用C定义的，C的编译时计算能力主要是极端的宏编程技术。
And what's more important, when making an OpenGL functions/extensions loader, how should I define those types?
除非你有特定的需要否则，完全按照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