Re: More function decorations II (pool_allocator, mt_allocator, debug, stl_list)

[Joe Buck <Joe dot Buck at synopsys dot COM>]

Gaby, I wish you wouldn't set the Reply-To: header; I don't believe
you intended that all replies to your messages be taken offlist.

On Mon, Apr 20, 2009 at 3:31 AM, Richard Guenther <rguenther@suse.de> wrote:
> > In my opinion adding attribute malloc to C++ new (_not_ the placement
> > new variants!) does not add any potential sources for miscompiles.

On Mon, Apr 20, 2009 at 11:49:11AM -0700, Gabriel Dos Reis wrote:
> Even when the operator new implementation just returns a pointer
> into a storage buffer statically allocated (therefore another object)
> in the problem?  Is this something documented for the attribute?

It seems that the malloc attribute requires that there be a barrier
to the analysis somewhere.

To a user of malloc, pointers returned by separate malloc calls never
alias.  But to an implementer of a memory allocator, of course there
is aliasing, because the data structures that represent the memory pool
are visible, most obviously for a simple allocator that just parcels
out chunks of a large array.

A user could overload operator new with an allocator that does something
weird (maybe reuse storage for equal objects), but that user wouldn't
be putting the malloc attribute on her "new" function.

It would appear that to prevent trouble, if a function with the malloc
attribute is inlined the malloc attribute has to go away (as the
implementation details could now be exposed).