But as long as the alloca'd memory is only accessed from within the same thread, it is -- AFAIK -- safe to call alloca() simultaneously from multiple threads, the same as malloc(). I think that qualifies as thread-safety by the usual definition: i.e. the function doesn't access statics or globals.
(Of course this will vary depending on the CRT. I don't think any UNIXes nowadays ship without threading support in the CRT, but Microsoft Visual C++ used to have separate thread-safe and non-thread-safe C libraries.)
I agree that doesn't tell you if the candidate is good at solving problems using C++, but there is potential to discover how deep their understanding is.
PS: I worked with code from the 1984 Macintosh days that was still in use in 2005. You could see where people had updated from Motorola 68020 to PPC and if it had not been stripped out some poor coder might have updated the remaining ASM to x86.
I just figured a good language lawyer, like a good real lawyer, would be able to both interpret the law (spec), but also tell you what would happen in reality if you violated it a certain way.
If you add up all the time it takes to write a particular system, I think you'll find debugging and fixing bugs to be one of the largest chunks of time, probably beating out the time it actually took you to write and possibly design the system. Obviously a design more suited to maintainability will decrease this somewhat.
Given this, I'd say this is an excellent question. Especially if the interviewee can tell you why it's a bad idea, or what the gotchas are with using 'delete this;'. It might not find developers with other positive characteristics like what makes for simple and elegant designs. But if you have a mix of questions to cover the many aspects of development in the interview, you should be good to go.
A) Running the code on another system to double check that the systems memory / OS has not been corrupted. I once wasted ~6 hours on a corrupted production box, so now the new rule is when system call fail double check it's not just the machine.
B) Double check that none of the memory allocation / book keeping memory had been over written, memory had not been freed twice etc.
Honestly, I usually try to do that type of stuff by direct code inspection. If it's failed once I am probably going to need to debug related code in the not to distant future so really understanding what's going on is important, but hack and slash debugging can be fun.
Then you can either litter break points and start stepping or load the core file in gdb, and start looking closer.
Is the not asshole answer to be stopping right before the malloc and taking note of memory consumption and determining how much malloc is trying to allocate?
When you start asking about how much memory malloc is asking for, that's a tip-off in the wrong direction for me too; malloc handles "out of memory" pretty gracefully.
1. Must it work according to the standard?
2. Is there a reason why it can't work?
3. Are you aware of it working or not working in any particular implementation?
4. Reasoning about how the relevant features might be implemented, can you guess whether it would work?
At some point candidates should express any doubts they feel about the advisability of actually using the technique, or about the conditions under which they would use it, and of course they should explain what further research they would do if the question came up in practice.
In my mind, a candidate can get full marks without actually knowing the answer to the question. I would actually prefer them not knowing, because then I'll learn more about how they think and how well they understand C++.
As the author says, he doesn't expect anyone to get it on their first try. It's more a test of if the candidate can figure the answer out or not. Would you rather have someone who can figure questions like this out on their own or someone who will dismiss this as "trivia"?
My old Sonicity C++ code, which was built on ACE, is littered with "delete this" calls for Reactor callbacks. Obviously, "delete this" is OK if you're on the heap and you can guarantee that the code isn't going to touch the object again. But what I remember most about that ACE Reactor code was how fragile the event handling was; "delete this" is a recipe for horrible memory corruption flaws.
This is what you get when your C++ interviewers decide that interviews are more about proving how smart they are than about qualifying candidates.