Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interesting C Interview Questions and Answers

thegeekstuff.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Interesting C Interview Questions and Answers

#21

Post by omra »

jdoliner wrote: post #14

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.

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 

        int main(void) {
                char *a = malloc(10);
                return 0;
        }
This one has memory that the OS cannot recover:

        #include 

        int main(void) {
                char *a = malloc(10);
                a = malloc(10);
                return 0;
        }

Re: Interesting C Interview Questions and Answers

#22

Post by mikeash »

omra wrote: post #21
jdoliner wrote: post #14

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.

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 int main(void) { char *a = malloc(10); return 0; } This one has memory that the OS cannot reco…

So if you run your second example a billion times or so, your OS will run out of RAM?

No, that's not how it works....

Re: Interesting C Interview Questions and Answers

#23

Post by Jare »

omra wrote: post #21
jdoliner wrote: post #14

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.

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 int main(void) { char *a = malloc(10); return 0; } This one has memory that the OS cannot reco…

To get rid of the hard memory leak in the second example, just call free(a) twice before returning. They don't call it pointer magic for nothing!

/sarcasm

Re: Interesting C Interview Questions and Answers

#25

Post by ajross »

kstenerud wrote: post #4

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 qual…

Not to defend question 10 per se (I think it's dumb too) I think your criticism is wrong. The ISO C standard declares argv as having type "char*", which clearly requires writability. I don't believe this is covered by an exception like the one for string literals.

Certainly on all real-world platforms with a conforming main() implementation (i.e. there are some embedded systems which have stubbed mains, or just use something like _start directly) argv is passed on the stack and is writable.

Re: Interesting C Interview Questions and Answers

#26

Post by kstenerud »

ajross wrote: post #25
kstenerud wrote: post #4

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 qual…

Not to defend question 10 per se (I think it's dumb too) I think your criticism is wrong. The ISO C standard declares argv as having type "char*", which clearly requires writability. I don't believe this is covered by an exception like the one for string literals. Certainly on all real-world platforms with a conforming main() implementation (i.e. there are some embedded systems which have stubbed mains, or just use s…

The char* formal parameter type is there for historical reasons. The implementation is under no obligation to ensure writability.

Also, while argv itself may be passed on the stack, the memory each entry of argv points to is not.

But once again, we're arguing esoteric edge cases that have no place in an interview, let alone in professional code.

Re: Interesting C Interview Questions and Answers

#27

Post by ajross »

kstenerud wrote: post #26
ajross wrote: post #25

Earlier quoted context omitted.

Not to defend question 10 per se (I think it's dumb too) I think your criticism is wrong. The ISO C standard declares argv as having type "char*", which clearly requires writability. I don't believe this is covered by an exception like the one for string literals. Certainly on all real-world platforms with a conforming main() implementation (i.e. there are some embedded systems which have stubbed mains, or just use s…

The char* formal parameter type is there for historical reasons. The implementation is under no obligation to ensure writability. Also, while argv itself may be passed on the stack, the memory each entry of argv points to is not. But once again, we're arguing esoteric edge cases that have no place in an interview, let alone in professional code.

Again, I think that's wrong. Can you cite anything in the standard that allows a non-writable argv? Again, the only comparable situation I can think of is the allowed implicit conversion of a string literal to char* even though the memory is allowed to be read-only. That doesn't apply here.

And the bit about argv not being passed on the stack is simply wrong on all real platforms. The argv[] array of pointers and the memory they point to is absolutely on the stack at process start.

Re: Interesting C Interview Questions and Answers

#28

Post by eswangren »

peteri wrote: post #16
throwaway54-762 wrote: post #13

Earlier quoted context omitted.

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.)…

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

I left the same comment before I saw yours. Whoever wrote this does not know C, they think they do because the use C++.

Re: Interesting C Interview Questions and Answers

#29

Post by kstenerud »

ajross wrote: post #27
kstenerud wrote: post #26

Earlier quoted context omitted.

The char* formal parameter type is there for historical reasons. The implementation is under no obligation to ensure writability. Also, while argv itself may be passed on the stack, the memory each entry of argv points to is not. But once again, we're arguing esoteric edge cases that have no place in an interview, let alone in professional code.

Again, I think that's wrong. Can you cite anything in the standard that allows a non-writable argv? Again, the only comparable situation I can think of is the allowed implicit conversion of a string literal to char* even though the memory is allowed to be read-only. That doesn't apply here. And the bit about argv not being passed on the stack is simply wrong on all real platforms. The argv[] array of pointers and the…

Hmm actually you are right on the writable part:

5.1.2.2.1 Program Startup: "The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination."

However, nothing says they must be on the stack. I ran the following program to test this:

    int main(int argc, const char * argv[])
     {
        char buff1[0x1000];
        char buff2[0x1000];
        printf("buff1 = %p\n", buff1);
        printf("buff2 = %p\n", buff2);
        printf("argv  = %p\n", argv);
        for(int i = 0; i
I passed it the params "1 2 3" and got the following:

    buff1 = 0x7fff5fbfe7b0
    buff2 = 0x7fff5fbfd7b0
    argv  = 0x7fff5fbff7f8
    arg 0 = 0x7fff5fbff970
    arg 1 = 0x7fff5fbff9e9
    arg 2 = 0x7fff5fbff9eb
    arg 3 = 0x7fff5fbff9ed
It seems odd that there's a 376 byte gap between what's clearly the stack and what addresses the arguments reside at. They also appear in ascending order despite the fact that the stack is descending (a required convention, maybe?). It's still pretty damn close to the stack so it might very well be the stack with a bunch of process-specific stuff in it, or it could just be that the OS put the start of the stack close to the startup parameters.

Either way, this is very esoteric stuff that has no place in an interview. I've read through the complete spec a number of times and I STILL get stuff wrong!

Re: Interesting C Interview Questions and Answers

#30

Post by humbledrone »

omra wrote: post #21
jdoliner wrote: post #14

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.

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 int main(void) { char *a = malloc(10); return 0; } This one has memory that the OS cannot reco…

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.

Post reply on HN