This is the mail archive of the 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 (Robert Dewar)  wrote on 02.01.04 in <>:

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

MfG Kai

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