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.
Just to be an onerous bastard: As the code involves undefined behaviour, it's superfluous to reason about any output.<p>Only values of type void* are valid arguments in case of the %p conversion specifier as there need not be a uniform pointer representation.
This is a bit of an idiotic question because one is not testing knowledge of computing or software systems, but rather trivial knowledge of an arcane corner of the language. Indeed, this question is an interview anti-pattern that I have historically labelled the "where-is-the-bathroom-in-my-house" question: if someone has not been in your house, they would not know, and if someone were in your house and had to take a leak, I trust they could figure it out. In my experience, these questions are most likely to be asked by intellectual midgets who themselves would not be able to answer an equivalent (but different) question.<p>So in the spirit of performing that experiment and exploring this interview anti-pattern, here's my counter-challenge, which I argue is intellectually equivalent:<p><pre><code> #include <stdio.h>
void
foo()
{
printf("in foo\n");
}
void
main()
{
void (*func)(void) = foo;
(************************************func)();
}
</code></pre>
What does that program do? Yeah, exactly: you just ran it. And you're surprised, aren't you? And most importantly: who cares? Certainly not I when I'm interviewing you -- where you can trust I will ask you deeper questions than language arcana...
I got the 4th question wrong; my only caveat is, professional C programmers probably all learn to avoid constructions like this in favor of more explicit ones.
These questions just show that C is inconsistent. If you have int x[5]; then sizeof(x) is 20, so x is some data of size 20. Yet if you do int y[5]; and then y=x, C refuses to do this even though the types match. That's because it is inconsistent: x is not really an object of size 20 to C, it is also partly a pointer. But then again it is not really a pointer. Which it is depends on confusing rules. If instead y and x were structs with 5 int fields, y=x would work.
The Ksplice blog is one of my all time favorite programming blogs. I am very happy it's back. If you haven't seen it before, it's well worth looking at the archive.<p>In question 2 I got tripped up because I assumed sizeof(int) == 8 on a 64 bit system. I also got question 4 wrong because I didn't know that &x gives a pointer to an array of size 5.
"...without the use of a computer."<p>And in this age, with technology so advanced, and computing resources so inexpensive ... why? Because it's the geek's athletic challenge? Whomever's brain holds the most memorized facts is the smartest brain in the world?<p>I'd guess someone would answer "because you need to <i>know</i> this stuff to be good at your programming job!" To which I reply: if you ever make the assumption that you <i>know</i> how some bit of code will work in a system, you're well on your way to becoming the infallible coder that no one likes to work with. This is why we have testing methodologies.<p>Yes, you need to be aware of this particular nuance of C. My answers were more high-level ("the address of the beginning of the array", "the next int in memory, not the next byte", etc) and I have no need to know the precise memory locations when I can ask the computer to tell me.
If you're interested in even more detail and discussion on pointers vs arrays, the book Expert C Programming by Peter van der Linden has several really good chapters on the subject. Plus, the whole book is a really great read.
I knew all these and I am self tought. Never did too much actual programming but I just enjoyed reading about this things and understanding how they work so over the years I've gained a ton of technical knowledge that (according to what I'm always reading on HN and reddit) the average programmer doesn't know (or care to know).<p>Can I get a job with the Ksplice team? :)
Quite good - I almost got the last one wrong. I did immediately realised my mistake and got it wrong again before nailing it but IRL there is no button to press to tell you you got it wrong (unit test maybe?) - there are much worse gotchas and more useful fringe functionality floating around though. What do these print for example.<p>int aiFoo[ 5 ] = { 1 }; printf( "%d", aiFoo[ 1 ] );
static int ls_aiFoo[ 5 ]; printf( "%d", ls_aiFoo[ 1 ] );<p>or how about int i = 5; int aiFoo[ i ]; which is valid C99 but not C89?<p>At any rate - much more important than learning the minutia of C is learning to get things done. If you are passionate about writing some OS you don't need to be taught - you would already know or be learning. It costs nothing but time...
Well, it got me on the pointer arithmetic questions. I remembered that C automatically handles pointer arithmetic (multiplying by sizeof(type)), however:<p>Question 2: I didn't think that x+1 would be interpreted as a pointer for some reason, so I guessed 0x7fffdfbf7f01. Wrong.<p>Question 4: I incorrectly thought that what I remembered about pointer arithmetic would apply here. 1 * sizeof(int) = 0x04, so I guessed 0x7fffdfbf7f04. Wrong.<p>I don't work in C professionally, but I'd like to not forget things. My error in question 2 shows forgetfulness, and my error in question 4 is from not ever completely mastering every nook & cranny in C.<p>How did the rest of HN do?
The third answer's explanation could be better than whats given :<p>" That is, whenever an array appears in an expression, the compiler implicitly generates a pointer to the array's first element, just as if the programmer had written &a[0] "<p><a href="http://c-faq.com/aryptr/aryptrequiv.html" rel="nofollow">http://c-faq.com/aryptr/aryptrequiv.html</a><p>Also remember that much fun could be had by studying the pre-processor up close .. another source of mind-bending fun.
If we could turn pedantry into electrical power, geeks on the internet could power the planet forever.<p>The takeaway summed the point up nicely although everyone's arguing over sizeof(int). Sure, there are cases when sizeof(int) is not 4 but that's not the point of the exercise. If you solved believing it was 8, you'd still be correct in my opinion.<p>I'm reminded of so many great articles with comments like "it's you're and not your"
Ignoring the sizeof(int) could be 4, one can code a 64-bit application that uses 32-bit pointers - yes it's rare - but in reality it's a 64-bit application, but just having small pointers - it's called the x32 abi (heh, and I read about it first here from this forum)<p><a href="https://sites.google.com/site/x32abi/" rel="nofollow">https://sites.google.com/site/x32abi/</a>
I got all right except 2 because I thought that sizeof(int)==8 on 64 bit systems.<p>Array vs. pointer is one of the more advanced interview questions I like to use to probe C knowledge. I don't actually expect any correct answers, just the knowledge that array != pointer.
I am a java programmer and got the first and the last answer correct and the last answer only because the explanation of the second and third one were good enough to understand the last one.<p>Learned something, so thanks for the link.
I learned a lot from this, thanks for posting. Mostly I learned how rusty my C skills have gotten in the years since I last used them.<p>Maybe time to bust out my K&R again.
In my humble opinion the only challenge here is guessing what sizeof(int) the author had in mind. A mild challenge would be asking about something that is not a part of the pointer arithmetic basics such as a[i] === i[a] and obfuscating a bit (e.g. "const char* i[] = {"Hello","world"}; char c = (2&*i[1])["Hello world"]; what is c? The guess about character encoding is as good as the guess about sizeof(int)).
This is something I like about Forth. It uses explicit dereferencing, so it's clear what address is being used.
<a href="http://home.claranet.nl/users/mhx/sf8/sf8.html" rel="nofollow">http://home.claranet.nl/users/mhx/sf8/sf8.html</a>
I'm pretty sure the code is undefined once you do x+1 (that is, treat an array like a pointer). Arrays are auto-converted to pointers in, for example, function calls, but until that is done doing arithmetic on them is undefined.