This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Marking C++ new operator as malloc?
On 9/9/07, Ross Smith <r-smith@ihug.co.nz> wrote:
> Gabriel Dos Reis wrote:
> > Joe Buck <Joe.Buck@synopsys.COM> writes:
> >
> > | On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
> > | > "Richard Guenther" <richard.guenther@gmail.com> writes:
> > | >
> > | > | On 9/8/07, Chris Lattner <clattner@apple.com> 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.