"Andrew Pinski" <[EMAIL PROTECTED]> writes: | On 9/7/07, Chris Lattner <[EMAIL PROTECTED]> wrote: | | > It is unclear whether this is safe. Nothing in the standard AFAIK | > requires the operator new be implemented in terms of malloc, and | > users are allowed to override it. | | I was looking for something else in the standard and found this (5.3.4/7): | [Note: If the library allocation function is called, the pointer | returned is distinct from the pointer to any other object. ] | | Which means it has to act like malloc.
As has been pointed out, that is not exactly true -- although I suspect the intent is to have the default operator new behaves like malloc. The difference is that, being distinct from a pointer to any other object is not the same as not aliasing any other pointer. Furthermore, the issue is more subtle/non-trivial for C++ because users can provide their own allocators. Consider the following: struct ChunkAlloc { ChunkAlloc(); void* allocate(size_t n); void* deallocate(void*) { } private: enum { size = 4096 }; char chunk[size]; // assume this is suitable aligned char* next }; ChunkAlloc::ChunkAlloc() : next(chunk) { } void* ChunkAlloc::allocate(size_t n) { if (n == 0) return malloc(1); if ((chunk + size - next) >= n) { char* mem = next; next += n; return mem; } throw bad_alloc; } Do you believe that allocator is prohibited by the C++ standard? Notice that the first pointer returned for non-zero memory chunk request has the same address (as void*) as the allocator object -- under usual GCC ABI. -- Gaby