【问题标题】:Bit Shift Operator '<<' creates Extra 0xffff?位移运算符“<<”创建额外的 0xffff?
【发布时间】:2017-03-31 00:09:11
【问题描述】:

我目前遇到了这个简单的位移问题。问题是 当我为短变量分配任何值并用 但是,对于'长',没关系。所以我想知道为什么会发生这种情况??


我的意思是,short 不应该读取超过 2 个字节,但是......它清楚地表明我的 short 值包含额外的 2 个字节,值为 0xffff。


我正在寻求你的智慧.. :)

This image describes the problem. Clearly, when the 'sign' bit(15) of 'short' is set to 1 AFTER the bit shift operation, the whole 2 byte ahead turns into 0xffff. This is demonstrated by showing 127(0x7f) passing the test but 0x81 NOT passing the test because when it is shifted, Due to it's upper 8. That causes to set Bit15(sign bit) to '1'. Also, Because 257(0x101) doesn't set the bit 15 after shifting, it turns out to be OK.

【问题讨论】:

标签: overflow bit-shift


【解决方案1】:

您的代码有几个问题。

首先,您正在对有符号变量进行位移操作,这可能会产生意想不到的结果。使用unsigned short 而不是short 进行位移,除非您确定自己在做什么。

您将short 显式转换为unsigned short,然后将结果存储回short 类型的变量。不确定您期望在这里发生什么,这是没有意义的,并且不会阻止任何事情。

问题与此有关。 129 &lt;&lt; 833024,一个值太大而无法放入已签名的 short。您不小心点亮了符号位,导致数字变为负数。如果您将其打印为 %d 而不是 %x,您会看到。

因为short 在作为参数传递给printf() 时被隐式提升为int,所以您会看到这个负数的32 位版本,它的16 个最相关的位相应地点亮。这就是领先的ffff 的来源。

long 没有这个问题,因为即使它的签名 long 仍然足够大,可以存储 33024 而不会重载符号位。

【讨论】:

  • Ohhhh.... 是的,我发现我应该使用“无符号值”进行操作,但我不知道 0xffff 来自“pirntf_parameter”!感谢您分享你的知识! ;)
猜你喜欢
  • 2012-04-09
  • 2018-07-27
  • 1970-01-01
  • 2012-04-15
  • 1970-01-01
  • 2011-02-02
  • 2021-08-16
  • 2018-04-13
  • 2010-10-02
相关资源
最近更新 更多