今天闲时写了一个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时就是同类型的了。

© 2008, bigwhite. 版权所有.

Related posts:

  1. 小心'溢出'陷阱
  2. 小心库函数调用的'陷阱'
  3. APR源代码分析-设计篇
  4. 关于宏定义切换以及屏蔽的例子
  5. switch语句性能考量