On 9/9/07, Ross Smith <[EMAIL PROTECTED]> wrote: > Gabriel Dos Reis wrote: > > Joe Buck <[EMAIL PROTECTED]> writes: > > > > | On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote: > > | > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > | > > > | > | On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote: > > | > | > I understand, but allowing users to override new means that the > > actual > > | > | > implementation may not honor the aliasing guarantees of attribute > > | > | > malloc. > > | > | > > | > | Well, you can argue that all hell breaks lose if you do so. A sane > > ::new > > | > | is required for almost everything :) > > | > > > | > I suspect the question is how to you distinguish a sane new from an an > > | > insane one. > > | > > | Does it matter? > > > > No, it does not. > > > > The reason is 3.7.3.1/2 > > > > [...] If the request succeeds, the value returned shall be a nonnull > > pointer value (4.10) p0 different from any previously returned value > > p1, unless that value p1 was subsequently passed to an operator delete. > > That's not sufficient. First, merely requiring pointers to be different > isn't the same as requiring them not to alias, which requires the blocks > of memory they point to not to overlap. Second, the standard only > requires the pointers returned by new to be different from each other, > not from any other pointer in the program. > > Probably the most common use of a custom new is to allocate memory from > a user-controlled pool instead of the standard free store. Somewhere in > the program there will be a pointer to the complete pool, which aliases > every pointer returned by that version of new. Any such pool-based new > doesn't meet the requirements of the malloc attribute.
That doesn't matter. What matters is object lifetime, which is properly preserved by a conforming pool allocator. Richard.
