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).
Sure, it can be important to know what these problems are and how to identify them if you should have to read through some terrible code written by someone else. Still, I think the author goes a bit far; it should be more important that you hire a programmer who doesn't produce this sort of code in the first place.
In the end I think there is no "best way" to technically test programmers; you're better off covering as many bases as possible with a bit of programming, a bit of documentation/explanation, some debugging, etc.
strncpy(argv[0], "NewName", 7);
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";
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.
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.
Well this is always true, so I guess that means there's no such thing as memory leaks in C. Checkmate garbage collectors.
An actual memory leak is when the amount of memory program allocates grows with runtime while the amount of data the program is processing remains the same.
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;
}
#include <stdlib.h>
int main(void) {
char *a = malloc(10);
a = malloc(10);
return 0;
}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.
No, that's not how it works....
/sarcasm
#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.
Depends on what you are studying. While I never had any specific "learn C" courses it is by far the most used language in other courses (OS programming, parallel programming, compiler construction, network programming, micro-controllers, graphics and game programming, security courses etc.). No other language comes close (a lot of the time a C++ compiler is used but the C subset is what ultimately has been used).
The G choice was always "No, looks good".
It's timed.