Can realloc be marked as a mallloc-like function?

Richard Guenther richard.guenther@gmail.com
Mon Jul 16 14:47:00 GMT 2007


On 16 Jul 2007 14:39:39 -0000, Wolfram Gloger <wmglo@dent.med.uni-muenchen.de
wrote:
> Hi,
>
> First, I assume we are talking about C realloc here, not just a
> "realloc-like" function which may have other semantics and for which
> __attribute_malloc__ may not be appropriate.
>
> > > It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
> > > return an address which can alias something else. But it isn't true
> > > for realloc. Now, the qestions are
> > >
> > > 1. Can gcc make such an assumption?
> >
> > No, it can't.  The returned memory may alias the original memory.
>
> After realloc(p, s) has returned non-NULL, the "original object"
> doesn't exist any more, hence there can't be any aliases.
>
> > > 2. Can realloc be marked as DECL_IS_MALLOC.
> >
> > ... with DECL_IS_MALLOC the following
> >
> > int *p;
> > p = malloc (4);
> > *p = 0;
> > p = realloc (p, 4);
> > *p = 1;
> >
> > will have VOPs that do not prevent re-ordering of the two stores.
>
> By that reasoning, consider:
>
>  int *p;
>  p = malloc (4);
>  *p = 0;
>  free(p);
>  p = malloc (4); /* this is very likely to return the same address as before */
>  *p = 1;
>
> What prevents the reordering of the stores in this case?
> Should we also remove __attribute_malloc__ from malloc :-)?
> IMHO this is an object lifetime issue not an aliasing issue.
>
> > > BTW, glibc also marks realloc with __attribute_malloc__.
> >
> > Which is wrong as well.
>
> I disagree.
>
> Of course, the gcc developers get to define the semantics of
> __attribute_malloc__, but according to the gcc manual, the attribute
> only refers to the _result_ of the attributed function, hence I would
> intuitively expect that I can safely mark:
>
> int *destroy_something_and_allocate_anotherthing(int *p)
> {
>         free(p);
>         return malloc(sizeof(int)); /* again very likely to return the
>                 same as the previous p */
> }
>
> as __attribute_malloc__.

I would agree with the above analysis if we made sure to apply proper escape
analysis on the allocation function arguments and mark the memory pointed to
as (at least) read from.  There is code in the alias machinery that
prevents this
from happening (? Danny, this may be only through the proposed patch for
32328, but can you comment on this?) correctly for functions marked with
the malloc attribute.

Richard.



More information about the Gcc mailing list