Re: Patch: malloc function attribute

[Richard Earnshaw <rearnsha at arm dot com>]

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

Agreed, I'm just sugesting that it is *less unreasonable* than assuming 
that growing the area won't change the area.  A particular implementation 
*could* guarantee that the pointer wouldn't change if the size were 
reduced.  Knowing this might be a particular win in terms of efficiency 
for some programs: allocate a block large enough for all cases, free what 
we don't need after building some data structure.

Such code is certainly not conforming to the ansi/iso standard, but then 
we weren't talking about those cases.

R.