I think alot of these examples use esoteric or just plain "bad" C code just in order to create pits for programmers to fall into. In real life you would avoid writing code like this precisely because of these problems. The author even mentions for at least one of the examples that he had to disable or ignore compiler errors/warnings to run the code.

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.

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?

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.

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?

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

zero will have argc == 0.

On my MBP with gcc 4.2.1, it does work -- I tried it before posting. (Your interpretation of what it does is correct.)

I think the best solution would be something like "Hope setproctitle() is available and use it".

Wow, question 12 is so bad that they completely ignore the C standard and make up rules (arguments evaluated left-to-right). There's no sequence point between function arguments.

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.

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.

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 < argc; i++)
        {
            printf("arg %d = %p\n", i, argv[i]);
        }
        return 0;
     }

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!

The location of process arguments on the stack (and environment variables) is just a convention between your kernel and system libc's crt0.a / the dynamic loader. (Not part of the C standard.)

Your program doesn't actually start executing at main(). It runs a bunch of code before it gets there, all of which is farther up the stack.

2, 3, 4, 7 are all bad questions too. It's pretty bad as collections of C questions go.