Comment by klodolph | Hacker News Reader

Comment by klodolph | Hacker News Reader

Parent Full thread

I was really surprised how many errors there were in the quiz.

Errors in the quiz:

3. (unsigned short)1 > -1: This will evaluate to 0 on systems where sizeof(short)<sizeof(int), and 1 on systems where sizeof(short)==sizeof(int). Yes, such systems exist. Old Cray supercomputers and various DSP processors don't have byte-addressable memory, only word-addressable, so they make all primitive types a word long.

5. SCHAR_MAX == CHAR_MAX: The person who wrote the quiz even ACKNOWLEDGES that the quiz is incorrect here and apologizes. This is implementation-dependent, it is 1 when char is signed and 0 when char is unsigned. Both types of systems exist. You can use -funsigned-char on GCC, for example.

11: int x; x << 31: This is only defined for some values on platforms where int has at least 32 bits. There exist systems where int has 16 bits, in which case this is undefined for all values. Old DOS PCs often used 16-bit ints, and I believe that ints were 16 bits when C was invented.

12: int x; x << 32: This is only undefined on systems where int has no more than 32 bits. There exist systems where int has more bits. Do a search for ILP64 if you wish to hear about such systems.

14: unsigned x; x << 31: Again, this is only defined on systems where int has at least 32 bits. See #11.

15: unsigned short; x << 31: This one is tricky. There are four different cases, depending on the size of int and whether sizeof(short)==sizeof(int).

15a: sizeof(short) == sizeof(int): defined for all x, since x gets promoted to unsigned.

15b: sizeof(short) < sizeof(int), int has less than 32 bits: defined for no x. I don't think any such systems exist.

15c: sizeof(short) < sizeof(int), int has at least 32 bits but less than 32 more than a short: defined for some x. This is the most common, with 16-bit short and 32-bit int.

15d: sizeof(short) < sizeof(int), int has at least 32 more bits than a short: defined for all x. This is the uncommon ILP64 system.

18: int x; (short)x + 1: This is outright incorrect. Casting int to short results in undefined behavior if the value cannot be represented as a short. Truncation is only guaranteed to occur for unsigned types.

The intro text explicitly defines those datatype sizes:

In other words, please answer each question in the context of a C compiler whose implementation-defined characteristics include two's complement signed integers, 8-bit chars, 16-bit shorts, and 32-bit ints. The long type is 32 bits on x86, but 64 bits on x86-64 (this is LP64, for those who care about such things).

Hm, okay... the intro text apparently disappears as soon as you click start.

Specifying those things is really weak anyways. "Here is a portability test on how the standard defines int's, but oh, assume this implementation".

I don't think it's intended as a portability test, but rather an implementation-defined vs undefined behavior test. And in practice it's safe to make assumptions about implementation-defined behavior as long as you're programming for general-purpose computers.

Regehr clarifies this in the comments section: "Regarding signed overflow being defined or not, compiler developers generally draw a sharp distinction between undefined behavior and implementation-defined behavior. 32-bit ints, 2's complement, etc. are examples of the latter and signed overflow is an example of the former. A lot of developers do not draw such a sharp distinction, which is why I made a point of asking questions about this issue."

For an example of signed overflow versus unsigned overflow, certain compilers are known to assume that int loop variables won't overflow. So "for (int i = 0; i != -1; ++i)" is transformed into "for (int i = 0; ; ++i)", since both are equal in the eyes of the C standard (both will iterate through all non-negative values that fit in an int, then both will invoke undefined behavior, so they are the same).

The funny part is that it's often better to use int exactly because of the undefined behavior on overflow. By signaling to the compiler that you don't intend to overflow a particular variable, it can optimize appropriately.

Things are pretty bad when even on the most well-known platform, with a fairly straightforward implementation of two's complement integers, the answers are not intuitive.

Fortunately, with a few simple coding guidelines you can avoid major pitfalls.

1. Always do bit operations on unsigned types.

2. Never overflow signed types.

3. Always shift less than the type width. I can name architectures which implement large shifts in three distinct ways.

4. Know that most integers get promoted to int or unsigned, so you need an explicit cast to get 64 bits on most platforms. So 1ULL << 48 is okay, 1U << 48 is bad.

5. Treat unsigned int / unsigned long as contagious, just like float and double.

Still ambiguous. Unsigned short to int or long expansion uses the internal 'widen' operator, which can either sign-extend or not (unspecified). Would have to specify a particular compiler to make the quiz fair (or add "depends upon compiler" to the choices).

No, expanding a short to int or long is never unpredictable. The C standard guarantees that the expansion will only ever occur if the resulting type can represent all values in the original type, and that the result will always have the same value as the input.

If int is 32 bits and short is 16 bits, then converting unsigned short to int will always give a value in the range [0, 0xffff]. No exceptions.

#4 is also platform dependent.

Longs are 32 bits on Windows(both 32 and 64), but are 32 for Linux 32-bit and 64 for Linux 64-bit. So the answer could be B or C there.

Reply on news.ycombinator.com