At least, it is a bug in VC8. That check won't happen. Reading Larry Osterman's recent posts "What's wrong with this code, part 15" and the answers, reminded me this behavior changed in VC8. If you check the result of new in code compiled with VC8, your code is wrong. The call to new will throw. Yes, your code worked in 5.0, 6.0, (maybe) 7.0 and 7.1, but it doesn't now.
You can get the old behavior if you link with nothrownew.obj. The linker will then make every call to new in your dll (or exe) non-throwing. This is incompatible with STL, or any other code that relies on new throwing.
The only other option is to use std::nothrow placement new. Don't do that.
If you are writing code that uses no throw semantics, you probably need those same semantics from the libs you link as well. If you are linking a lib that was coded expecting new to return NULL rather than throw, the linker doesn't know that. In VC8 it will link the throwing version. Linking with nothrownew.obj tells the linker that everything needs the old, non-standard version of new that returns NULL.
What if you are using 2 libs? One that needs the non-standard new, and one that needs the standard new? If that is the case, package one in it's own dll, or change it so you have consistency on the definition of new. Don't bother trying to get the linker to do something magical. It won't. The linker makes a decision on what new means and that's it for the entire dll.
History of new through the VC's:
In VC5.0, and VC6.0 you basically got nothrow new and had to jump through hoops to get a throwing version. MFC did use a throwing version, but it doesn't throw std::bad_alloc. Also new(std::nothrow), had bugs which caused it to throw in some circumstances. For users of non throwing new, life was good. For everyone else, not so much. See this msdn article "Don't Let Memory Allocation Failures crash your lagacy STL Application" for the details.
In 7.0 and 7.1 the VC++ team attempted to do something clever. The version of new you get is controlled by the first significant header in the first obj linked. This means a large number of examples do exactly what you'd expect. It also means there are corner cases where it is almost impossible to understand what's happening. You could force a standard complying new by linking thrownew.obj.
In 8.0 the VC++ team decided to clean up many standard compliance issues. Now the C++ standard is used. Full Stop. If you want the old behavior, you must link nothrownew.obj.
Finally, I must thank Martyn Lovell for explaining the background on this issue, and clarifying some of the details. If there are any errors here they are due to me alone.