首先，问题的前提是：不同数据类型的实际大小是依赖于编译器的具体实现的，那么假设在一个long为8B的平台，使用long作为例如memcpy的参数进行数据移动，并且指定的要移动的字节数超过了4B所能表示的最大值，那么如果将此代码移动到一个long为4B的平台，代码就会出现问题，因为此时的long已无法再存储之前的数据了。（这里涉及到data model的问题，long确实在windows下是4B，而在Linux或macOS下是8B(理论来源，实践来源-可测试多平台下的输出结果)）
这一问题的产生是由于具体类型的大小控制权并没有掌握在编程语言一方，而是由编译器所决定的（这是一个疑点，为什么最开始没有从语言层面就对不同类型的具体大小做出约束，反而是让编译器去负责，难道是在最开始的时候为了增强具体的实现灵活性吗？）
关于明确指明了数据长度的类型，例如int8_t来说。如果它的出现是为了从编程语言层面直接对数据类型大小做出限制，那么它是类型别名又该如何解释。
就是说既然是类型别名，又是如何做到的对编译器的具体实现做出约束的。
此问题同时还和 size_t、提高代码可移植性和可靠性的数据类型头文件 (Fixed width integer types)、C++11以前如何规定不同平台中数据类型的长度 相关，进行总结