1

I am getting

Msg(3:4130) Bitwise operations on signed data will give implementation defined results

this warning in QAC. The code like

functionName( a | b | c);

QAC on PIC micro controller code. Anyone can explain. what is this warning and how to avoid this warning.

6 Answers6

3

Don't use signed integers for bitwise operations, use unsigned.

That is what the warning is telling you.

You don't show the types of a, b and c, so it's hard to be more specific.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • So you are saying function((unsigned int)a | (unsigned int)b | (unsigned int)c) type converting the variable will avoid right ?? –  Apr 13 '15 at 12:06
1

There are multiple way in which the negative numbers are represented in systems.

  1. Signed magnitude : The first bit is 0 then number is positive and if the first bit is 1 then the number is negative.

  2. 2's complement

  3. 1's complement

So C never mandate the way the numbers are represented in different systems so this line is in accordance with the how the numbers are represented in systems.

There is littel-endian and big-endian representation which you should be aware of before doing bitwise operation.

Gopi
  • 19,784
  • 4
  • 24
  • 36
1

In your code functionName( a | b | c);

You are calling this function functionName with a | b | c where as a argument where | performs the bitwise operations. Performing bitwise operations (|) on signed integers (a,b,c) will return the implementation defined results.

You can avoid this warning by typecasting the variables a,b,c as below

functionName( (unsigned)a | (unsigned)b | (unsigned)c)

The above code will change the type of a,b,c so that the QAC warning can be avoided

Community
  • 1
  • 1
Embedded C
  • 1,448
  • 3
  • 16
  • 29
1

Bitwise(|,&) operation on signed data(INT,LONG) will give u the implementaton related result. you can avoid it by using by type converted to unsigned before performing bitwise operation.

0

Expression (127)|(-127) on 8-bit integers results in -0 in 1's complement or in -1 in 2's complement.

CiaPan
  • 9,381
  • 2
  • 21
  • 35
0

There are different representation schemes for negative numbers,
for example these three (using 8bit examples).

  • complement 2 : -n == ((0xff ^ n) +1)
  • complement 1 : -n == ((0xff ^ n))
  • signed magnitude: -n == ( 0x80 | n )

Equalities are different

  • complement 2 :

    (-1 | -2)
    == ((0xff ^ 1)+1) | ((0xff ^ 2)+1)
    == (0xfe+1) | (0xfd+1)
    == (0xff) | (0xfe)
    == 0xff
    == (0xfe +1)
    == ((0xff ^ 1) +1)
    == -1
    == -( ((1+1) & (2+1)) -1 )

  • complement 1 :

    (-1 | -2)
    == (0xff ^ 1) | (0xff ^ 2)
    == (0xfe) | (0xfd)
    == (0xff)
    == (0xff ^ 0x00)
    == -0
    == - ( 1 & 2 )

  • signed magnitude :

    (-1 | -2)
    == ( 0x80 | 1 ) | ( 0x80 | 2 )
    == (0x81) | (0x82)
    == (0x83) == (0x80 | 3)
    == -3
    == -( 1 | 2 )

So that is what "implementation defined" means, depending on your compiler: 

(-1 | -2) == -3 == -( 1 | 2 )  
(-1 | -2) == -0 == -( 1 & 2 )  
(-1 | -2) == -1 == -( ((1+1) & (2+1)) -1 )

"Considering values of these variables as negative,
just because the highest bit is 1,
is stupid, they are just bits!" you say?
Or maybe, "The values will never be so high, and definitly not semantically negative either."

Well, then do not use signed int for them.
That's what QAC wants to tell you.

If you do not happen to already know it,
I bet you will never guess which representation your compiler
(or at least most todays compilers for actual hardware-implemented ALUs) uses.

Yunnosch
  • 26,130
  • 9
  • 42
  • 54