今天闲时写了一个Demo测试程序，目的：测试64位编译下使用mmap映射共享内存的能力。程序很简单，大致如下结构：
#define MAP_SPACE_SIZE  (4*1024*1024*1024)
unsigned long int ms_sz = MAP_SPACE_SIZE;
…. ….
ptr = mmap( NULL, ms_sz, PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0 );

我尝试在64位编译模式下映射4G的空间，结果mmap返回MAP_FAILED，errno返回EINVAL，通过查看mmap的manual得知，很可能是ms_sz这个参数的问题，当该参数实际值为0或<0时，mmap如是返回错误。输出一下ms_sz，居然真的是零，让我有些不解，但细致想了以后，觉得还是有道理的。

我遂尝试了重新定义MAP_SPACE_SIZE，结果印证了我的分析是正确的。
当#define MAP_SPACE_SIZE  (4*1024*1024*1024L)时，ms_sz输出 4294967296；
当#define MAP_SPACE_SIZE  4294967296时，ms_sz同样输出 4294967296；

这里简单说一下，首先 (4*1024*1024*1024)是不是常量呢？从程序的输出结果来看，编译器没有直接将其与数值常量4294967296等价，而是执行了计算过程。这也是我们第一次得到0这个结果的原因了。由于没有显式的后缀，编译器按照int, long, long long的顺序识别数值类型，编译器在识别4*1024*1024*1024中的各个数值时，显然将各个值识别为int了，而乘积的结果也放到了一个int临时存储区中，4G对于一个32bit的int刚好过庞大，结果溢出，导致该值变成了0，将0赋给ms_sz(unsigned long int)，同样也是0，这就是原因。

当#define MAP_SPACE_SIZE  (4*1024*1024*1024L)时，由于显式给出了L后缀，编译器将运算结果直接存储在8 byte的long中，这样ms_sz自然很easy的得到了正确的值 4294967296。

当#define MAP_SPACE_SIZE  4294967296时，这时4294967296可是一个常量，标准的整型常量，编译器发现unsigned int无法将其装下，遂将之识别为long int类型了，这样该值赋给ms_size时就是同类型的了。