Interesting C Interview Questions and Answers • Hacker News Board

Re: Interesting C Interview Questions and Answers

#31

Post by throwaway54-762 » Wed, Aug 29, 2012, 12:15 AM UTC

kstenerud wrote: post #29

ajross wrote: post #27

Earlier quoted context omitted.

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 modiﬁable 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[0x10…

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

Re: Interesting C Interview Questions and Answers

#32

Post by ambrice » Wed, Aug 29, 2012, 12:16 AM UTC

mturmon wrote: post #19

tedunangst wrote: post #10

Earlier quoted context omitted.

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

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?

Re: Interesting C Interview Questions and Answers

#33

Post by JBionics » Wed, Aug 29, 2012, 2:14 AM UTC

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.

Re: Interesting C Interview Questions and Answers

#34

Post by tedunangst » Wed, Aug 29, 2012, 2:23 AM UTC

mturmon wrote: post #19

tedunangst wrote: post #10

Earlier quoted context omitted.

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

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

Re: Interesting C Interview Questions and Answers

#35

Post by tedunangst » Wed, Aug 29, 2012, 2:27 AM UTC

ambrice wrote: post #32

mturmon wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Interesting C Interview Questions and Answers

#36

Post by tedunangst » Wed, Aug 29, 2012, 2:36 AM UTC

kstenerud wrote: post #29

ajross wrote: post #27

Earlier quoted context omitted.

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 modiﬁable 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[0x10…

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.

Re: Interesting C Interview Questions and Answers

#37

Post by mturmon » Wed, Aug 29, 2012, 3:44 AM UTC

ambrice wrote: post #32

mturmon wrote: post #19

Earlier quoted context omitted.

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

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?

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

Re: Interesting C Interview Questions and Answers

#38

Post by lurker14 » Wed, Aug 29, 2012, 4:47 AM UTC

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

Re: Interesting C Interview Questions and Answers

#39

Post by pfedor » Wed, Aug 29, 2012, 4:48 AM UTC

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.

The code in question 4 is not a memory leak by any reasonable definition of memory leak. Allocating a fixed amount of memory and using it until the program terminates, without ever bothering to free it, is a perfectly valid programming practice. Why should it trouble anyone more than say a statically allocated global array? In fact, it's a wiser thing to do than religiously freeing everything at exit.

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.

Re: Interesting C Interview Questions and Answers

#40

Post by pfedor » Wed, Aug 29, 2012, 6:41 AM UTC

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.

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