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

[Gabriel Dos Reis <dosreis at gmail dot com>]

On Mon, Apr 20, 2009 at 1:58 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
> 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.

You are absolutely right; but then that was done behind my back :-(
Anybody who knows how to convince gmail not to do that for me
for free, please tell me the magic incantation...

>
> 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.

I agree.

>
> 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).
>

The thing that gets me a bit worried is that the standard allocation
function 'operator new' is *replaceable* -- not overloadable.  That means
that user definition gets to replace libstdc++ definition.  Now, what
do we annotate?  The declaration in the header, or the definition
hidden somewhere in a .cc file?  I suspect the latter is not useful since
the compiler would not see it.  However, the former makes me a bit
nervous, because now we would be adding an annotation that the
user does not know of (and should not care about) that is not described
by the C++ standards.

-- Gaby