This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: malloc function attribute
- To: richard dot earnshaw at arm dot com
- Subject: Re: Patch: malloc function attribute
- From: Horst von Brand <vonbrand at inf dot utfsm dot cl>
- Date: Tue, 30 Nov 1999 15:19:37 -0300
- cc: law at cygnus dot com, Mark Mitchell <mark at codesourcery dot com>, ghazi at caip dot rutgers dot edu, green at cygnus dot com, gcc-patches at gcc dot gnu dot org
Richard Earnshaw <rearnsha@arm.com> said:
> > In message <19991129074845D.mitchell@codesourcery.com>you write:
> > > I believe that if you know something about your realloc
> > > implementation, then you can know that realloc will return the same
> > > pointer. So, I can imagine something like:
> > >
> > > int *ip = (int *) malloc (8);
> > > int *ip2 = (int* ) realloc (ip, 16);
> > >
> > > and that the programmer knows that `ip' and `ip2' *are* aliases. I've
> > > just looked at the C standard and I don't see any reason to believe
> > > that using `ip' in this code yields undefined behavior,
> > Egad. I'll accept this. I don't have anything to counter it. With this
> > in mind we need to not consider realloc or xrealloc as being malloc-like.
> > Bummer.
> >
> > > Maybe I'm off base, but I thought that the malloc attribute said the
> > > new pointer doesn't alias anything.
> > You're correct.
> I can't see why any reasonable programmer would expect that to work...
>
> However, a much more reasonable expectation is that
>
> int *ip = (int *)malloc(16);
> int *ip2 = (int *)realloc(ip, 8);
> foo(*ip);
> would do the right thing in that it would release the tail of the
> allocated memory area, but not move things about. This would be
> sufficient to break the no-aliasing assumptions.
Why should that be reasonable? Perhaps the implementation keeps malloced
objects in different arenas, sorted by size. In that case, it might very
well decide to move the now-8-byte object if it is running out of space in
the 16-byte-arena. Or it might just be too stupid to be able to reclaim the
tail, and gets a new block anyway. AFAIKS, the intent of malloc and ilk is
to _hide_ what is going on behind the scenes, and by making assumptions
like the above the program is just plain broken.
--
Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513