（待完善）Same data type with different length
首先，问题的前提是：不同数据类型的实际大小是依赖于编译器的具体实现的，那么假设在一个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以前如何规定不同平台中数据类型的长度 相关，进行总结
macOS测试结果
| type | Byte | bit |
|---|---|---|
| char | 1B | 8b |
| unsigned char | 1B | 8b |
| short int | 2B | 16b |
| unsigned short int | 2B | 16b |
| int | 4B | 32b |
| unsigned int | 4B | 32b |
| long int | 8B | 64b |
| unsigned long int | 8B | 64b |
| long long int | 8B | 64b |
| unsigned long long int | 8B | 64b |
| pointer | 8B | 64b |
Linux测试结果
同macOS相同
| type | Byte | bit |
|---|---|---|
| char | 1B | 8b |
| unsigned char | 1B | 8b |
| short int | 2B | 16b |
| unsigned short int | 2B | 16b |
| int | 4B | 32b |
| unsigned int | 4B | 32b |
| long int | 8B | 64b |
| unsigned long int | 8B | 64b |
| long long int | 8B | 64b |
| unsigned long long int | 8B | 64b |
| pointer | 8B | 64b |
Windows测试结果
| type | Byte | bit |
|---|---|---|
| char | 1B | 8b |
| unsigned char | 1B | 8b |
| short int | 2B | 16b |
| unsigned short int | 2B | 16b |
| int | 4B | 32b |
| unsigned int | 4B | 32b |
| long int | 4B | 32b |
| unsigned long int | 4B | 32b |
| long long int | 8B | 64b |
| unsigned long long int | 8B | 64b |
| pointer | 8B | 64b |
对于64位的Linux和macOS，int is 32-bit, long and pointer are 64-bit，即它们采用的data model为LP64 or 4/8/8
对于64位的Windows，int and long are 32-bit, pointer is 64-bit，即采用的data model为LLP64 or 4/4/8
