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.
