This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> Andreas Schwab <schwab@suse.de> writes:
>
> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> |
> | > Andreas Schwab <schwab@suse.de> writes:
> | >
> | > [...]
> | >
> | > | > Even on an segmented architecture it needs to be possible to compare
> | > | > pointers. If it were not necessary, why would realloc() docs talk about
> | > | > "(possibly moved) block".
> | > |
> | > | The standard actually says "(which may have the same value as a
> | > | pointer to the old object)". You can test for a subset of the "same
> | > | value" condition by comparing the representation, and on an
> | > | implementation where the indeterminate value of a pointer is never a
> | > | trap representation you can even use == or !=, but that is not
> | > | strictly compliant.
> | >
> | > Well, the notion of "strictly conforming" is an oxymoron.
> |
> | s/strictly conforming/guaranteed by the standard/
>
> By that do you include conforming programs?
Sorry, I don't get your point. A conforming program can make
assumptions that the standard does not meet, simply by relying on one
conforming implementation's extension, like in the example I gave
above. Such assumptions are simply not portable to all (possible)
conforming implementations.
> If not, I can sympathize with Bruce's fears that GCC is heading the
> wrong and dead road.
I did not say anything about how GCC should behave here.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."