On 11 Sep 2007 07:24:44 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > [...] > > | > I think I'm getting confused. Perhaps you could sum up in a single > | > email the argument for why putting this attribute in our standard > | > headers is safe, even in view of possible replacement in user programs? > | > | My argument goes like "We can safely put attribute malloc on all overloads > ^^^^^^^^^^^^^^^^^ > | of new as C++ starts lifetime of a new object in the target and accesses to > | old objects at that location invoke undefined behavior". I claim that you > | cannot construct a testcase with no undefined behavior that has two > | pointers returned from a call to 'new' alias. > > I don't think I understand the claim. The C++ does not say anything > about all overloads in terms of aliasing. IT makes claims about > specific `operator new's. Could you elaborate on why it is OK to > annotate all overloads?
Sorry for the wrong terminology, I think I mean all implementations of void* operator new(std::size_t) throw (std::bad_alloc); void* operator new[](std::size_t) throw (std::bad_alloc); void* operator new(std::size_t, const std::nothrow_t&) throw(); void* operator new[](std::size_t, const std::nothrow_t&) throw(); that is, not only annotating libsupc++ implementation but assuring the attribute is set by changing the C++ frontend. Richard.
