码迷,mamicode.com
首页 > 其他好文 > 详细

一个移位操作引发的程序Bug

时间:2015-05-16 18:23:42      阅读:133      评论:0      收藏:0      [点我收藏+]

标签:移位操作   ipv6   汇编   编译器   

          最近在开发一个有关IPV6的项目,碰到一个非常奇怪的问题,在计算IPV6的子网掩码的时候,网络前缀为8,16,48,80,112能计算正确,当网络前缀为32,64,96计算错误。这个问题花了近一天的时间定位和修改。计算IPV6子网掩码的函数如下:

#include<stdio.h>
#include<string.h>
#define MAX_IP_SEG 4
class CIPV6Address
{
public:
        CIPV6Address()
		{
			memset(m_uiIPSeg, 0, sizeof(m_uiIPSeg));
		};
		void Output(unsigned int uiPrefixLen)
		{
			printf("PrefixLen_%u=%08x:%08x:%08x:%08x\n", uiPrefixLen,m_uiIPSeg[0],m_uiIPSeg[1],m_uiIPSeg[2], m_uiIPSeg[3]);

		}
		void fillNetMask(unsigned int uiPrefixLen)
		{
			unsigned int uiLoc=uiPrefixLen/32;
			unsigned int uiBits=uiPrefixLen%32;
			for(unsigned int i = 0;i < uiLoc; ++i)
			{
                m_uiIPSeg[i] = 0xFFFFFFFF;
			}
			if (uiPrefixLen < 128)
			{
				m_uiIPSeg[uiLoc] = (0xFFFFFFFF<<(32-uiBits));
 			}
			Output( uiPrefixLen);
		};
private :
	unsigned int m_uiIPSeg[MAX_IP_SEG];
};
int main()
{  
	CIPV6Address addr;
	addr.fillNetMask(16);
	addr.fillNetMask(32);
        addr.fillNetMask(48);
	addr.fillNetMask(64);
        addr.fillNetMask(80);
        addr.fillNetMask(96);
	return 0;
}

上面程序的输出如下:

  技术分享

技术分享

       可以看到网络前缀为32,64,96的子网掩码计算错误。到底是什么原因导致了这个结果呢?开始怀疑是算法出现了问题,通过检查发现算法没有问题,于是心中充满了各种疑惑,然后写了一个小程序来进行测试。如下:

    技术分享技术分享

        大家可以不看下面,猜猜上面程序的输出是什么?

        通过运行发现,两句打印的结果不同,第一个uiResult是一个非常大的值,而uiRes是0。这里唯一的差别是前面使用变量uiBits,而uiBits的值为0,下面是直接使用0,然后进行移位。如下:

输出如下:uiResult=4294967295

                   uiRes=0

而后者是我们预期的结果, 这也就是函数fillNetMask计算结果错误的直接原因,但是为什么会出现这种情况呢?

接下来看看两种情况的汇编指令:

第一情况:

unsigned int uiBits=0;

011E344E  mov         dword ptr [uiBits],0

unsigned int uiResult = (0xFFFFFFFF<<(32-uiBits));

mov         ecx,20h

011E345A  sub        ecx,dword ptr [uiBits]

011E345D  or         eax,0FFFFFFFFh

011E3460  shl         eax,cl

011E3462  mov        dword ptr [uiResult],eax

     printf("%u\n",uiResult);

011E3465  mov        esi,esp

011E3467  mov        eax,dword ptr [uiResult]

011E346A  push       eax 

011E346B  push       offset string "%u\n" (11E5C18h)

011E3470  call       dword ptr [__imp__printf (11E82B8h)]

011E3476  add        esp,8

011E3479  cmp         esi,esp

011E347B  call        @ILT+460(__RTC_CheckEsp) (11E11D1h)

从上面011E3460  shl         eax,cl 可以看出,移位指令向左移动了cl位,这个cl是移位操作数的低4位寄存器。32的低四位为0,其实没有向左移。


第二种情况:

unsigned int uiResult =(0xFFFFFFFF<<(32-0));

00BE344E  mov        dword ptr [uiResult],0

     printf("%u\n",uiResult);

00BE3455  mov        esi,esp

00BE3457  mov        eax,dword ptr [uiResult]

00BE345A  push       eax 

00BE345B  push       offset string "%u\n" (0BE5C18h)

00BE3460  call       dword ptr [__imp__printf(0BE82B8h)]

00BE3466  add        esp,8

00BE3469  cmp        esi,esp

00BE346B  call        @ILT+460(__RTC_CheckEsp) (0BE11D1h)

通过观察,发现上面的汇编指令中没有shl移位操作指令,编译器在编译阶段发现unsigned int 向左移动32位,可能会溢出,优化了该操作,直接将结果赋值为0.,如下这条赋值语句。

00BE344E  mov        dword ptr [uiResult],0

这就导致了上面两者的结果不同。同时第二种情况编译的时候也会出现编译告警,提示移位操作大于数据类型的最大长度。

技术分享

技术分享

       由此可以看出,为了保证移位操作的正确性,应该保证移位个数不能大于等于数据类型的最大位数,如果出现这种情况,可能会得到意向不到的结果。

修改方式

     由于是溢出导致的结果错误,立马想到的是采用如下下的方式修改

技术分享

上面的结果会是我们的预期吗?按照我们上面的理论,应该是正确的,我们来看看运行的结果是多少。

编译运行:

技术分享

技术分享

发现上面的结果也不是我们预期的,真的好纠结,难道和编译器的行为有关?或者和操作系统有关?或者上面总结的理论错误?各种猜测。 起初自己各种尝试,都得不到正确的结果,后来一个同事跟我说,你编译的是32位程序还是64位,因为32位的程序unsigned long和unsigned int都是四个字节。而g++默认的编译方式是32位的,为了验证这个想法,我以64位的方式进行编译。

g++ -m64 shift.c –o shift

./shift

uiResult=0

发现运行结果正确。

主要原因是在32位程序sizeof(unsigned int)=sizeof(unsignedlong)=4,向左移位32,都可能会溢出。

而64位平台,sizeof(unsigned long)>sizeof(unsignedint)。

为了保证在不同平台上能运行正确,我没有选择上面的修改方式,而是选用了下面的修改方式。

voidfillNetMask(unsigned intuiPrefixLen)
           {
                 unsigned intuiLoc=uiPrefixLen/32;
                 unsigned intuiBits=uiPrefixLen%32;
                 for(unsigned int i = 0;i < uiLoc; ++i)
                 {
                    m_uiIPSeg[i] = 0xFFFFFFFF;
                 }
                 if (uiPrefixLen < 128)
                 {  
                        if(0 == uiBits)
                        { m_uiIPSeg[uiLoc] = 0;}
                        else
                        { m_uiIPSeg[uiLoc] =(0xFFFFFFFF<<(32-uiBits));
                         }
                 Output(uiPrefixLen);
           };

本文总结一句话:在进行移位操作时,移位的位数不能超过数据类型的最大位数,同时也不能对负数进行移位。同时需要注意32位和64位平台数据类型的差异。

一个移位操作引发的程序Bug

标签:移位操作   ipv6   汇编   编译器   

原文地址:http://blog.csdn.net/xiaoding133/article/details/45769837

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!