Why would a C++ compiler not eliminate null check of pointer returned by new?

Question

Recently I ran the following code on ideone.com (gcc-4.3.4)

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <new>

using namespace std;

void* operator new( size_t size ) throw(std::bad_alloc)
{
     void* ptr = malloc( 2 * 1024 * 1024 * 1024);
     printf( "%p\n", ptr );
     return ptr;
}

void operator delete( void* ptr )
{
    free( ptr );
}

int main()
{
    char* ptr = new char;
    if( ptr == 0 ) {
        printf( "unreachable\n" );
    }
    delete ptr;
}

and got this output:

(nil)
unreachable

although new should never return a null pointer and so the caller can count on that and the compiler could have eliminated the ptr == 0 check and treat dependent code as unreachable.

Why would the compiler not eliminate that code? Is it just a missed optimization or is there some other reason for that?

Answer 1

I think this is very simple and you have two fundamentally different things confused:

1. malloc() can return anything, in particular zero.

2. the global C++ allocation function void * operator new(size_t) throw(std::bad_alloc) is required by the standard to either return a pointer to the required amount of storage (+ suitably aligned), or otherwise exit through an exception.

If you want to replace the global allocation function, it is your responsibility to provide a replacement that abides by the rules of the standard. The simplest version looks like this:

void * operator new(size_t n) throw(std::bad_alloc) {
  void * const p = std::malloc(n);
  if (p == NULL) throw std::bad_alloc();
  return p;
}

Any serious implementation should actually contain a loop to call the registered new-handler until the allocation succeeds, and only throw once there are no more new-handlers.

The program that you wrote is simply ill-formed.

---

Digression: Why is this new defined that way? Consider the standard allocation sequence when you say T * p = ::new T();. It is equivalent to this:

void * addr = ::operator new(sizeof(T));  // allocation
T * p = ::new (addr) T();                 // construction

If the second line throws (i.e. construction fails), the memory is deallocated with the corresponding deallocation function. If the first call fails, though, then the execution must never reach the second line! The only way to achieve this is by exiting through an exception. (The no-throw versions of the allocation functions are only for manual use where the user code can inspect the result of the allocator before proceeding to construction.)

Answer 2

C++11 is clear on the issue:

void* operator new(std::size_t size); : ... 3 Required behavior: Return a non-null pointer to suitably aligned storage (3.7.4), or else throw a bad_alloc exception. This requirement is binding on a replacement version of this function.

You hit Undefined Behavior.

[edit] Now, why would this impede optimization? Compiler vendors tend to spend their time dreaming up optimizations for code patterns that are commonly used. There's usually little benefit for them to optimize for faster Undefined Behavior. (Some UB may be well-defined on that particular compiler and still be optimized, but the above example likely wouldn't be).

Answer 3

I think you're expecting way too much of the optimizer. By the time the optimizer gets to this code, it considers new char to be just another function call whose return value is stored on the stack. So it doesn't see the if condition as deserving special treatment.

This is probably triggered by the fact that you overrode operator new, and it's beyond the optimizer's pay grade to look in there, see you called malloc, which can return NULL, and decide that this overridden version won't return NULL. malloc looks like Just Another Function Call. Who knows? You might be linking in your own version of that, too.

There are a couple other examples of overridden operators changing their behavior in C++: operator &&, operator ||, and operator ,. Each of these has a special behavior when not overridden, but behave like standard operators when overridden. For example, operator && will not even compute its right hand side at all if the left hand side evaluates as false. However, if overridden, both sides of the operator && are computed before passing them to operator &&; the short-circuit feature goes away completely. (This is done to support using operator overloading to define mini-languages in C++; for one example of this, see the Boost Spirit library.)