You scored 0 out of 20. Note: Sometimes scores are reported incorrectly  sorry about that. I think it's a bug in the quiz plugin for WP that I'm using. I hope you found this quiz to be useful and/or entertaining, and please write a comment
or mail me if you find a mistake. As I said in the introduction, it was intended to be easy for experienced C programmers. In reality, integer bugs are hard to avoid not so much because the individual issues are extremely complicated, but rather because integer
operations are everywhere and their corner case bugs get mixed in with algorithmic difficulties and other programming problems. I have another integer quiz in the works that will be more difficult.
Your answers are highlighted below.
Question 1
WRONG

What does the expression 1 > 0 evaluate to?

0


1


undefined

Question 1 Explanation:
Ok, great. That one was a freebie. Of course one is greater than zero.
Question 2
WRONG

What does the expression 1U > 1 evaluate to?

0


1


undefined

Question 2 Explanation:
C has both signed and unsigned types, creating the potential for confusion when these are mixed. The simple version of the rule for resolving this situation (we'll get to the real version shortly)
is that unsigned wins. In other words, if a signed value is compared against an unsigned, the signed value is cast to unsigned and then the comparison is performed between two unsigned values. Therefore, this comparison is actually between 1 and UINT_MAX,
which evaluates to 0. Good C programmers often avoid mixing signed and unsigned values in the same expression. Good C compilers warn about this, but GCC only does so at fairly high warning levels.
Question 3
WRONG

What does the expression (unsigned short)1 > 1 evaluate to?

0


1


undefined

Question 3 Explanation:
In this question, two signed values are being compared. In other words, the rule about converting one operand of a comparison to unsigned if one of them is unsigned does not apply. This is because
C "promotes" both operands to arithmetic operators to int type before performing the operation. The rule for promotion states that an unsigned value is promoted to a signed int if (as is the case for promoting an unsigned short to an int) this can be done
without losing values. On the other hand (as we saw in the previous question) an unsigned int is not promoted to signed int because this would change large values into negatives. The full rules for promotions are a bit more complicated than this, for example
to handle the case of types like long that may be wider than int.
Question 4
WRONG

What does the expression 1L > 1U evaluate to on x8664? On x86?

0 on both platforms


1 on both platforms


0 on x8664, 1 on x86


1 on x8664, 0 on x86

Question 4 Explanation:
This one is a little tricky because it asks you to analyze a feature interaction. On x8664, int is shorter than long. Therefore, an unsigned int can be promoted to long, making the comparison
signed. The comparison thus becomes 1L > 1L, which is false. On x86, int and long are the same size. Therefore, int cannot be promoted to long without changing values. On this platform, the comparison becomes UINT_MAX > 1U, which is true.
Question 5
WRONG

What does the expression SCHAR_MAX == CHAR_MAX evaluate to?

0


1


undefined

Question 5 Explanation:
Sorry about that  I didn't give you enough information to answer this one. The signedness of the char type is implementationdefined, meaning the each C implementation is permitted to make
its own choice, provided that the choice is documented and consistent. ABIs for x86 and x8664 tend to specify that char is signed, which is why I've said that "1" is the correct answer here.
Question 6
WRONG

What does the expression UINT_MAX + 1 evaluate to?

0


1


INT_MAX


UINT_MAX


undefined

Question 6 Explanation:
The C standard guarantees that UINT_MAX+1 is 0.
Question 7
WRONG

What does the expression INT_MAX + 1 evaluate to?

0


1


INT_MAX


UINT_MAX


INT_MIN


undefined

Question 7 Explanation:
Overflowing a signed integer is an undefined behavior.
Question 8
WRONG

What does the expression INT_MIN evaluate to?

0


1


INT_MAX


UINT_MAX


INT_MIN


undefined

Question 8 Explanation:
When using two's complement integers, INT_MIN has no representable inverse. Moreover, trying to compute it is an undefined behavior in C.
Question 9
WRONG

Assume x has type int. Is the expression x<<0...

defined for all values of x


defined for some values of x


defined for no values of x

Question 9 Explanation:
Whoops... I thought this was always defined but as a couple of commenters point out, a negative value cannot be leftshifted even by zero bit positions.
Question 10
WRONG

Assume x has type int. Is the expression x<<1...

defined for all values of x


defined for some values of x


defined for no values of x

Question 10 Explanation:
Shifting a 1 into the sign bit is an error in C99. Therefore, shifting a large value such as INT_MAX left by one bit position is an undefined behavior. Other values can be safely leftshifted.
Question 11
WRONG

Assume x has type int. Is the expression x<<31...

defined for all values of x


defined for some values of x


defined for no values of x

Question 11 Explanation:
This is basically the same situation as the previous question. A 1 cannot be leftshifted into, or past, the signed bit. Therefore, I believe that 0 is the only value of type int that can be
leftshifted by 31 bit positions without executing an undefined behavior.
Question 12
WRONG

Assume x has type int. Is the expression x<<32...

defined for all values of x


defined for some values of x


defined for no values of x

Question 12 Explanation:
Shifting (in either direction) by an amount equalling or exceeding the bitwidth of the promoted operand is an error in C99.
Question 13
WRONG

Assume x has type short. Is the expression x<<29...

defined for all values of x


defined for some values of x


defined for no values of x

Question 13 Explanation:
Operands to shift operators are promoted before the shift executes. Therefore, the fact that 29 is not less than 16 is irrelevant and a shiftpastbitwidth error does not occur.
Question 14
WRONG

Assume x has type unsigned. Is the expression x<<31...

defined for all values of x


defined for some values of x


defined for no values of x

Question 14 Explanation:
Any value whose promoted type is "unsigned" can be legally shifted by an amount that is nonnegative and also less than the width of the unsigned type.
Question 15
WRONG

Assume x has type unsigned short. Is the expression x<<31...

defined for all values of x


defined for some values of x


defined for no values of x

Question 15 Explanation:
This one was just to make sure you've been paying attention. Since unsigned short is promoted to int, it is illegal to shift a 1 bit into or past the sign bit. If we shifted the value by 15
or fewer positions, the result would be defined for all values that can be stored in an unsigned short.
Question 16
WRONG

Assume x has type int. Is the expression x + 1...

defined for all values of x


defined for some values of x


defined for no values of x

Question 16 Explanation:
Evaluating this expression is an undefined behavior iff x is INT_MAX.
Question 17
WRONG

Assume x has type int. Is the expression x  1 + 1...

defined for all values of x


defined for some values of x


defined for no values of x

Question 17 Explanation:
Since C's additive operators are leftassociative, this expression is undefined iff x is INT_MIN. If these operators were rightassociative, the expression would be defined for all values of
x.
Question 18
WRONG

Assume x has type int. Is the expression (short)x + 1...

defined for all values of x


defined for some values of x


defined for no values of x

Question 18 Explanation:
Any value of type int, after being truncated to short and then promoted back to int, can be safely incremented as long as the int type is wider than the short type.
Question 19
WRONG

Assume x has type int. Is the expression (short)(x + 1)...

defined for all values of x


defined for some values of x


defined for no values of x

Question 19 Explanation:
Ok, that was an easy one. Of course the cast to short occurs too late to prevent the undefined behavior.
Question 20
WRONG

Does evaluating the expression INT_MIN % 1 invoke undefined behavior?

who knows

Question 20 Explanation:
A bug in the quiz software prevented me from creating two correct answers for this question. But here's the explanation: This construct is widely treated as undefined by real C compilers because
making it welldefined would reduce performance of generated code. My reading of the C99 standard is that it is not undefined. YMMV.