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

[Richard Guenther <rguenther at suse dot de>]

On Tue, 21 Apr 2009, Gabriel Dos Reis wrote:

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

No, it would be always invalid to transition malloc attribute semantics
to inlined code.

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

Yes, so?  The malloc attribute is a way to prune the points-to set
based on language semantics that says that the returned object
during its lifetime does not alias with other objects.  So,

char storage[...];

T *p = new T();
tmp = storage[0];

invokes undefined behavior if p points to storage[0].  This is just
the same as

union { int i; float f; } u;

u.i = 1;
tmp = u.f;

which invokes undefined behavior as well (ok, GCC has a language
extension that makes it valid, but it is not a strictly conforming
program).  If you end u.i lifetime by

u.f = 0;

then you can read from u.f (obviously).

Richard.