10 ms·
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
by DCoder 14y ago
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).
- klodolph 14y agoHm, okay... the intro text apparently disappears as soon as you click start.
- sausagefeet 14y agoSpecifying those things is really weak anyways. "Here is a portability test on how the standard defines int's, but oh, assume this implementation".
- gpvos 14y agoThings 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.
- klodolph 14y agoFortunately, 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.
- pdw 14y agoI 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."
- klodolph 14y agoFor 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.
- JoeAltmaier 14y agoStill 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).
- klodolph 14y agoNo, 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.