This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
jsm@polyomino.org.uk (Joseph S. Myers) wrote on 02.01.04 in <Pine.LNX.4.58.0401021859470.3037@digraph.polyomino.org.uk>:
> On Fri, 2 Jan 2004, Gabriel Dos Reis wrote:
>
> > I think we'd better off not listing realloc for reasons exposed in
> > this thread.
>
> Then we'd better have appropriate wording so that users can determine
> whether their realloc-like function is one that can have the attribute or
> not (depending on the specification of how their function may be used).
> Certainly, a function that mallocs space for the new copy of the data,
> copies it then frees the old space is a candidate for the attribute - but
> so surely is one that copies the data somewhere temporary, frees the old
> space then mallocs the new space (even if the pointers might sometimes
> happen to have the same bit-pattern).
Unfortunately, it essentially depends on the client.
*If* you use realloc() as it was intended - that is, never reuse any
pointer value that pointed into the block before unless the new pointer is
NULL - then it should be safe to give the attribute to realloc().
If, on the other hand, you compare the old and new pointer (no matter if
legally via bit copy or illegally via ==), so you can as an optimization
not update other pointers into that block, *then* having the attribute on
realloc can lead to bugs.
Incidentally, the same works (breaks) for malloc() free() malloc() chains,
except that's a much less likely coding style.
MfG Kai