7
#define SCALE (1 << 31)

#define fix_Q31_80(x) ( (int) ( (float)(x)*(float)0x80000000 ) )
#define fix_Q31_SC(x) ( (int) ( (float)(x)*(float)SCALE      ) )

int main()
{
    int fix_80 = fix_Q31_80(0.5f);
    int fix_sc = fix_Q31_SC(0.5f);
}

Why are the values fix_80 and fix_sc different? 

fix_80 == Hex:0x40000000
fix_sc == Hex:0xc0000000
Danijel
  • 8,198
  • 18
  • 69
  • 133
  • Who knows? UB is UB, [IB is IB](http://stackoverflow.com/questions/26331035/why-was-1-31-changed-to-be-implementation-defined-in-c14). Don't do it if you want predictable results. – David Schwartz Jan 18 '17 at 10:43
  • Because, even if the results are well defined on your implementation (which they may not be) `(1 << 31) != 0x80000000` – Peter Jan 18 '17 at 10:45
  • 9
    just don't use signed integer types when bit shifting – Sander De Dycker Jan 18 '17 at 10:46
  • @Danijel This 0x80000000 is a positive integer constant that can have type long. At the same time 1 << 31 is an integer expression that yields a negative number. – Vlad from Moscow Jan 18 '17 at 10:46
  • 5
    `1 << 31` is UB for 32-bit `int`. Use `1U << 31` which has a the same type as `0x80000000` in a system with 32-bit `int`. – ouah Jan 18 '17 at 10:47

3 Answers3

13

1 << 31 is undefined behavior on most platforms (e. g., systems with 16-bit or 32-bit int) as its result cannot be represented in an int (the resulting type of the expression). Don't use that expression in code. On the other hand 1U << 31 is a valid expression on systems with 32-bit int as its result is representable in an unsigned int (the resulting type of the expression).

On a 32-bit int system, 0x80000000 is a (relatively) big positive integer number of type unsigned int. If you are lucky (or unlucky) enough to not have demons to fly out of your nose by using 1 << 31 expression, the most likely result of this expression is INT_MIN which is a (relatively) big negative integer number of type int.

ouah
  • 142,963
  • 15
  • 272
  • 331
5

All integer constants have a type. In the case of 1, the type is int. On a system with 32 bit integers, 1 << 31 gives a number which is too large to be represented as an int. This is undefined behavior and therefore a bug.

But 0x80000000 will work as expected, because on a 32 bit system it happens to be the type unsigned int. This is because decimal constants and hexadecimal constants behave differently when the compiler goes looking for what type they should have, as explained here.

As several people have mentioned, don't use bitwise operators on signed types.

Community
  • 1
  • 1
Lundin
  • 195,001
  • 40
  • 254
  • 396
1

0x80000000 is a big number which needs 32 bit to represent that number. This means on a 32 bit system (or in a 32 bit compatible application) an int is too small. So use unsigned long instead:

#define SCALE (1u << 31)

#define fix_Q31_80(x) ( (unsigned long) ( (float)(x)*(float)0x80000000u ) )
#define fix_Q31_SC(x) ( (unsigned long) ( (float)(x)*(float)SCALE       ) )

int main()
{
    unsigned long fix_80 = fix_Q31_80(0.5f);
    unsigned long fix_sc = fix_Q31_SC(0.5f);
}
gmug
  • 773
  • 5
  • 11