This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can realloc be marked as a mallloc-like function?

On 16 Jul 2007 14:39:39 -0000, Wolfram Gloger <

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]