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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Tue, Apr 21, 2009 at 4:08 AM, Richard Guenther <rguenther@suse.de> wrote:

>> > 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).
>
> It effectively goes away as it is only an annotation for the function
> call semantics and we have no way to annotate an inlined body somehow.

That so today only because our current internal representation
of programs is not expressive enough.  However, I do not
think that is an intrinsic semantics of inlining.  Given our current
path, it would be long before we get there. And when we do, it
would be uncomfortable to debug.

>
>> 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.
>
> We annotate the declaration in the header. ?Because we reasoned that
> any conforming implementation of operator new has semantics that makes
> that annotation valid (if the operator is not inlined, but then the
> annotation goes away anyway).

I believe there are unclear aspects of  the reasoning.  For example,
 the pointer returned by the allocated as described above meets
the standard semantics, yet is also pointing into the statically
allocated object; no?


>
> Richard.
>