This is the mail archive of the gcc@gcc.gnu.org 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: malloc attributes and realloc


Kaveh R. Ghazi wrote:

 > I don't understand your reasoning here. C does not permit general
 > pointer comparisons, or rather does not provide defined semantics
 > for all such comparisons, for example, you cannot use > on pointers
 > and expect it to create a well-ordering of pointers.

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.

The run time code for a given compiler is of course one place where you can rely on semantic behavior of undefined code if your compiler defines it. So this code in libiberty is fine, provided that the compiler knows that it has to respect this requirement.

For application code, usually you want to avoid attaching yourself to
one particular compiler, though some people make an exception for GCC,
and for example there are Ada customers who are perfectly happy to use
GNAT specific stuff knowing that it is guaranteed to work on all GNAT
compilers (e.g. the guarantee that the Ada type Standard.Integer is
identical to the C type int).

It is indeed interesting that pointer ordering is not guaranteed by
the standard. The conceptual model of pointers in C is a base and
offset, and you can only compare pointers if the base pointers are
the same (except that null is a special case). In practice, as you
note, pointer comparison does usually work, and most likely we should
decide to guarantee that it works as a GCC extension that can be
relied on.




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