This test would be much more useful if they put all the errors into a broken string class, and asked you to find the bugs. Glancing at a broken class and seeing all the standard C++ bugs "pop out" is a useful skill for a C++ programmer. But instead of defining an actual, useful class with a bunch of bugs, they use horrendously nonsensical and broken code fragments. For example, I can't even figure out what the GrowArray function is supposed to do.

It's sort of like memorizing a chess board: A chess expert can memorize an actual game-in-progress quickly. But if you just place a bunch of random pieces around a chess board, a chess expert can't memorize it any better than anybody else.

The later examples with memchr are less painful, because memchr actually has well-specified behavior. But even there, the code (most likely) dereferences a pointer one past the end of an array, which is (1) invalid C++ and (2) not on their list of possible bugs. Granted, memchr is an internal compiler function, so it's allowed to rely on undefined behavior. But if this is a multithreaded system, that code potentially corrupts the heap's bookkeeping data structures while memchr is running.

Just looking at the first part of this test is like listening to somebody drag their fingernails across a blackboard. I'm sure that they're a lovely company, but ugh. To paraphrase Wolfgang Pauli, that code's so bad it's not even buggy—it's just semi-coherent nonsense.

Another interesting aspect of this test: Both the code examples and the bugs are pre-STL, pre-boost, and pre-TR1. For example, there's no question asking why you can't put a std::auto_ptr into an STL collection. And a huge fraction of the bugs in the test could be avoided by making rudimentary use of modern C++ APIs. Granted, some companies have legitimate reasons to avoid std::vector and std::tr1::shared_ptr. But avoiding those classes makes C++ vastly more error prone, which is usually a poor tradeoff in the modern world.