

Interesting C Interview Questions and Answers - giZm0
http://www.thegeekstuff.com/2012/08/c-interview-questions/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheGeekStuff+%28The+Geek+Stuff%29

======
kstenerud
Question 10 is a bad question. The host environment is under no obligation to
provide you with pointers to writable memory in argv. Furthermore, this is
veering off from C knowledge into C trivia.

Question 12 is even worse, as the processing order is implementation defined.
On my compiler, it prints out 60..40..60.

C questions should be designed to show whether or not the candidate can write
robust, professional quality code, not to test esoteric knowledge that even
the interviewer can't get right.

I was asked questions like these in an interview once. It was such a massive
red flag to me that I went with another company (the final straw was arguing
over the size of int, which he insisted was always 32 bits).

~~~
tedunangst
Further to point one, it's under no obligation to provide you with writable
memory of the size you'd like.

    
    
        strncpy(argv[0], "NewName", 7);
    

WTF does 7 come from, the source or the destination?

~~~
mturmon
Question 10 is just crazy broken. I'm not a standards expert, but I don't
think argv[0] is guaranteed to be big enough to hold the 7 characters (plus
\0) of NewName (i.e., even if it is writable, it may not be big enough).

As the comments said, argv[0] does not have to point to writable memory,
because argc can be 0. In this case argv[0] is supposed to be NULL, which
would segfault the program.

If you had to solve this question (it would be better not to ask it, because
you don't learn much), I think the solution:

    
    
       argv[0] = "NewName";
    

would be better. It's at least shorter.

~~~
ambrice
It also wouldn't work. This just reassigns your local copy of argv[0] to a
different memory location. Also, in what circumstances can argc be 0?

~~~
tedunangst

        int main()
        {
            char *args[] = { 0 };
            execve("./zero", args, 0L);
        }
    

zero will have argc == 0.

------
jdoliner
_Well, Though the above code is not freeing up the memory allocated to ‘ptr’
but still this would not cause a memory leak as after the processing is done
the program exits._

Well this is always true, so I guess that means there's no such thing as
memory leaks in C. Checkmate garbage collectors.

~~~
omra
Generally modern operating systems free any memory left that the program is
not using, but is still accessible. However, if you overwrite an old pointer,
there is no way that the operating system could catch that.

To illustrate the difference, I wrote two quick programs.

This one has memory that the OS can recover:

    
    
            #include <stdlib.h>
    
            int main(void) {
                    char *a = malloc(10);
                    return 0;
            }
    

This one has memory that the OS cannot recover:

    
    
            #include <stdlib.h>
    
            int main(void) {
                    char *a = malloc(10);
                    a = malloc(10);
                    return 0;
            }

~~~
humbledrone
The OS always recovers all of the memory from a process that has terminated
(barring horrible kernel bugs), and it doesn't need to look through the
process image for pointers that need to be freed.

When a process allocates memory, the kernel doesn't give it a physical memory
address. It gives it a virtual address, which, when accessed, will be mapped
to some physical address. The kernel has to keep track of which virtual
addresses map to which physical addresses for each process, and it stores
these mappings in a data structure called a "page table". At all times, the
kernel knows what memory segments are in use by a given process.

So, when a process exits, the kernel can just look at its page table to see
what memory had been allocated to it. Provided that no other processes shared
the same memory, it can free it.

------
joezydeco
Don't give me hints in the title of the question! That kind of wrecked the
challenge.

------
mitjak
I've studied most of these as part of my introductory C course in university.
Are they really that interesting?

~~~
throwaway54-762
None of these are especially interesting C questions... Most rely on
assumptions about the x86 architecture and GCC (stack grows downwards,
ordering of stack variables in memory (not registers), ...).

#3 notes a warning for main not returning int, but doesn't point out that
without stdlib.h, malloc() and free() will be declared implicitly with
incorrect types. (Edit: this produces a warning on 4.7 GCC and Clang 3.0.)

Almost all of these questions have something wrong with them other than what
the author is pointing out. I question the author's familiarity with C.

~~~
peteri
Also the casts to (char *) from malloc suggest that the author is a C++
programmer.

~~~
pfedor
There's a discussion in "The Practice of Programming" of which is a better
style when programming in straight C. The argument for casting was that could
make porting to C++ easier. The argument against it went like that (hope I'm
not botching it): if the appropriate header file was not included and
consequently malloc() was implicitly assumed to return an int, then without a
cast assigning the return value of malloc to say char* would likely trigger a
warning, but the cast will silence the warning. This could be a real bug if
the convention for returning an int was different from returning a pointer
(say if one was returned via a register and the other wasn't.)

~~~
peteri
Or if you were programming on an 8086 in large memory model where int is 16
bit and a pointer is 32 bit (16 bit segment, 16 bit offset)

This makes me wonder if anyone ever did a compiler where malloc returned a
segment + offset (I think that gives a 48 bit pointer) for a 386 class
machine.

------
mikeash
I wonder why there are so many articles about C getting passed around where
the author just doesn't know the language that well, or at the very least
ventures well outside the boundaries of his knowledge. Where are the _good_
articles on C, and why don't they ever show up on HN?

~~~
diggan
The question is why it's on 12th place on the index. Don't people read
articles before they press the little arrow?

------
JBionics
For those of you interested, the first stage in the SpaceX interview process,
at least for the flight software group, is a series of questions like these,
with A-G multiple choice answers. You had to identify the class of bug.

The G choice was always "No, looks good".

It's timed.

------
romac
Here is another interesting C/Objective-C Q&A:
<http://www.eosgarden.com/en/articles/objc-quizz/>

------
lurker14
Is there a reason for any modern compiler to support linking to functions like
gets() without setting an "--use-unsafe-libraries" flag?

