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


gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 03.01.04 in <m34qvdq5jp.fsf@uniton.integrable-solutions.net>:

> Russ Allbery <rra@stanford.edu> writes:
>
> | Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
> |
> | > 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.
> |
> | Right.  I'm fairly sure that it's not possible to write a portable alloca
> | implementation without compiler extensions (although that particular
> | extension is ubiquitous).  It's the kind of facility that is best
> | implemented internal to the compiler, in the program that already
> | thoroughly understands the architecture of the target host.
>
> And I will point out that libstdc++ depends on that pointer ordering
> behaving "correctly" in its implementation of std::less<T*>.

Does it?

That is, is that specified to work for two independent objects (as opposed  
to two different parts of the same object)?


MfG Kai


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