11 ms·
They really should be listing these answers in terms of sizeof(int) instead of assuming all 64-bit platforms have sizeof(int) == 4. Pointers are confusing in C,
by matthavener 15y ago
They really should be listing these answers in terms of sizeof(int) instead of assuming all 64-bit platforms have sizeof(int) == 4. Pointers are confusing in C, but so is the common assumption that sizeof(int) is always 4.
- marshray 15y agoYep. I could have used the hint about what the output of %p looks like (I missed the leading 0x). Of course nobody's keeping score, but that doesn't seem essential to the question.
- rwg 15y agoOr they could use C99's int32_t in the problem's code to make the size of the integer explicit... (Or just state that sizeof(int) == 4 on this hypothetical system.)
- wdaher 15y agoI don't disagree, but I thought it was nicer for there to be a more concrete, actual memory address for the answer. I thought about explicitly stating "sizeof(int) is 4 on this system" in the intro blurb, but that primes you a bit more than I'd like for the answer to #2, so I thought it was a little cleaner not to.
- philh 15y agoI feel that anyone who doesn't already know "it depends on sizeof(int)" isn't going to get it anyway; I was briefly thrown off because I thought "surely if sizeof(int) matters like I think it does, I would have been told what it is?" But I'm more annoyed that I failed the last two by not understanding C than that I failed the second by guessing sizeof(int) incorrectly.
- calloc 15y agoMy first instinct was that sizeof(int) was the same width as the system architecture (64 bits)... specifically because you mentioned it was a 64 bit system. Either way, after I realised that sizeof(int) == 4 the test was surprisingly simple. Are pointers really that hard to grasp?
- TeMPOraL 15y agoIsn't the assumption that sizeof(int) = platform type in bytes (e.g. 4 for 32-bit and 8 for 64-bit platforms)? I expected int on 64-bit platform to be 8 bytes in size.
- shin_lao 15y agoAbsolutely not, on Windows 64 for example sizeof(void *) == 8 and sizeof(int) == 4.
- jedbrown 15y agoThat is true on 64-bit Linux too, but on Windows64 sizeof(long)==4. See LP64 versus LLP64.
- fmota 15y agoIt depends on your platform AND on your compiler, so just saying "Windows 64" isn't enough information. Conceivably, there are compilers for "Windows 64" such that sizeof(int) == 8. Your point (that int isn't a qword on all 64bit architectures) still stands. But your statement is potentially incorrect.
- adestefan 15y agoThe OS ABI basically defines what the compiler will do. While it's possible to run a compiler in ILP64 mode on Windows 64, you won't get too far if you try to pass a 64-bit integer >4^32 into a Windows system call.
- tptacek 15y agoIs there a common 64 bit architecture that is ILP64 as opposed to LP64?
- wdaher 15y agohttp://en.wikipedia.org/wiki/64-bit#64-bit_data_models http://en.wikipedia.org/wiki/64-bit#64-bit_data_models has a few examples -- but I think the answer is basically no?
- ajross 15y agoNo. The gotcha of course is on the other side. Win64 is P64, so a long won't (!!?@#!) hold a pointer. Edit: also, pedantry: the assignment of types to sizes is part of the ABI, not the architecture.
- apaprocki 15y agoIn AIX on POWER you can choose between LP64, LLP64, or ILP64.
- cjensen 15y agosizeof(int) is either 2 or 4 on all reasonable architectures. On all modern and reasonable architectures, it must be 4. Short answer: if sizeof(int)=8, then you lose either the 2 byte integer, or the 4 byte integer. This would make it harder to minimize memory footprint in programs which work with large amounts of data. The reason for this is that char, short, int, long, and long long are the only names you have for various integer sizes. Since sizeof(char) is fixed at 1 and sizeof(char) <= sizeof(short) <= sizeof(int) if you make int eight bytes, you must either drop the two-byte or four-byte integer since you only have one name left for it. Dropping one of those types will make programmers unhappy since they packing structs careful is a valid thing to do for memory minimization in large-memory programs. Note that int32_t and friends are not valid names since they MUST be a typedef for one of char, short, int, long or long long. Disclaimer: if C11 has fixed this, I'm ignorant of it.
- ajross 15y agoC99 specified stdint.h, which includes int16_t/uint16_t. So compliant compilers are required to support it even if it doesn't map to a built-in type. So you won't lose the short. That said, it wouldn't make it any less insane; so no one does this and in fact int is 32 bits everywhere except microcontrollers (and 8086, for the tiny handful of people writing BIOS or bootloader code).
- cjensen 15y agoEach of the intXX_t typedefs are optional. Each typedef is available iff the implementation has a type which is exactly XX bits.
- ajross 15y agoRight, which it does: we're talking about ABI variations within a single architecture. The OS and toolchain enforcing ILP64 vs. LP64 semantics on C programs has nothing to do with the i386's ability to operate on 16 bit chunks.
- 15y ago
- Erwin 15y agoWell, sizeof(int) (and short, and long!) could also be 1, and %p could print out the pointer address as a roman numeral. All legal according to standard. What commonly used platforms have a 64-bit ints? The only one I vaguely recall are really, really old versions of Solaris. After a while IIRC they decided that ILP64 was too much of a PITA and went with LP64.
- jedbrown 15y agoThe standard requires that "int" be able to represent from -32767 to +32767. Unless "byte" is redefined to contain a different number of bits, this means that sizeof(int) >= 2. Similarly, long has a range that requires at least 32 bits.
- Erwin 15y agosizeof(char) is 1 per definition and also one byte, but not necessarily 8 bits. Apparently some DSPs cannot address an 8-bit quantity -- they're not easy to find but I've found a comp.lang.c posting where Jack Klein mentions a 32-bit Sharp DSP with CHAR_BIT = 32 (so sizeof(char) == sizeof(int) == 1 !) and a Texas Instruments TMS32F28xx DSP with a 16 bit CHAR_BIT. On such a system, C99 might not define int8_t but you could use int8_least8_t. My guess is that they are more common than 64-bit ints but they might be supported by their own weird C Compiler/toolchain.
- caf 15y agoThe interesting thing about such architectures is that the common stdio idiom: int c; while ((c = getchar()) != EOF) { does not work properly on them.