This is the mail archive of the
mailing list for the GCC project.
Re: malloc attributes and realloc
firstname.lastname@example.org (Robert Dewar) wrote on 02.01.04 in <3FF544C5.email@example.com>:
> It is indeed interesting that pointer ordering is not guaranteed by
> the standard.
False. *Generic* pointer ordering is not supported; ordering of pointers
to the same object certainly *is* supported.
> 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.
It is actually sometimes a hardware/os issue if it does work. That is,
does the hardware punish you for handling (not dereferencing) invalid
pointers, and does the os actually make pointers invalid when you tell it
you no longer need them?
This would become relevant if gcc was ported to 286 or 386 protected mode
with far pointers, i.e. using segment registers; and I think you actually
do get pointer trap representations in that context - after free(p), even
looking at p might indeed cause a hardware exception.
As long as gcc only uses flat memory, though, it is extremely unlikely
that there will ever be any pointer trap representations. (v86 mode or x86
real mode certainly don't have any, nor has any x86 flat memory model.)