Also note that libc string functions generally seg-fault when passed invalid addresses (including NULL). Implicitly expecting more sophisticated error handling in this scenario is silly.

So, you either go back to the source and ask for more info, or you take a stab at what is the right thing to do.

In this case that wasn't possible, so I assumed the worst, and I think that simply noting that there is a potential problem there would already score you points with the interviewer because they'd realize you spotted that the specification was incomplete, it didn't tell you what to do in case of invalid input.

I think this may be a cultural thing. C programmers are very much used to the standard not defining the behaviour of some things, e.g. what happens when you call strcmp(str, NULL). Segfaulting is expected here, and easy to track down.

(I would use some assert()s if a function could cause silent memory corruption; but this particular function either works (valid string), segfaults (NULL) or cannot detect a problem (stray pointer).)

Yes, that's more or less the problem with lots of code.

I'm not saying your code is invalid or that it won't work, but 'defensive' programming says:

- assume your input is total garbage

- handle all correct situations correctly

- handle all garbage gracefully or throw an error depending on what the circumstances dictate

I'm also missing the stackframe handling, but as you said, this is the 'meat', that meat needs a bit of scaffolding to work.

Oh definitely. I agree. I assumed though that the "problem" itself was the main aim here, not testing if someone can write scaffolding error checking code.

How far do you go? Check that the memory isn't mapped as read only? ;) Check that there's actually some memory mapped into that address space?

Obviously you need both skills, but they're pretty related I'd say. If you can solve low level problems you can probably think through any potential issues, invalid inputs, edge cases etc and churn out code to deal with them.

I guess my issue is I don't see what being able to solve this says about someone, apart from "isn't completely terrible at programming".

Defensive programming is not always the correct assumption though.

any assumption is wrong, but when given the choice between two assumption (safe vs unsafe) safe is best.

I did note in my 'answer' that the problem wasn't specified fully.