This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
On Fri, 2 Jan 2004, Kaveh R. Ghazi wrote:
> Hum, that is surprising. If we can't rely on pointer ordering, then
> libiberty/alloca.c wouldn't work since it uses exactly this ordering
> to detect the stack growth direction and also to detect when storage
> can be freed.
We clearly ought to document exactly what extensions to pointers we
support beyond what the C standard specifies.
E.g.,
* ordered comparison, for valid pointers only, between pointers not in
same object (signed or unsigned?).
* casting to different (pointer or integer) types and adding integer
offsets (not just the cast to another type and straight back that the C
standard permits), provided that alignment constraints are satisfied at
all times, at all times the pointer points within the original valid
object (OR maybe within a narrower object with bounds implied by some
previous operation) or just past the end of such, and the final access is
in a type permitted by the aliasing rules (given the effective type of the
object).
* with -fno-strict-aliasing, treating each object as a block of bytes that
can be accessed with any types whatever.
I don't know if these are in fact extensions we support (though the
description of -fno-strict-aliasing ought to be what it does). But I
doubt that anything involving using pointers to freed memory is among what
we support, as long as we remember that GCC must work for compiling
malloc/free themselves and pointers that are invalid or nonaliasing
outside those functions may be valid or aliasing inside their
implementations.
--
Joseph S. Myers
jsm@polyomino.org.uk