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


Andreas Schwab <schwab@suse.de> writes:

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

Can you point me to any of your useful programs that does not make any
assumptions about the implementation it is using?

|                                         A conforming program can make
| assumptions that the standard does not meet, simply by relying on one

No. A conforming program can use any of aspect that the standard says
implementation-defined, which the implementation ought to document. 

The primary point is what we do want to document as far as GCC is
concerned.  If you don't have any useful answer for that, I believe it
is waste of time to continue this subthread.  

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

And the primary issue, here as brought as underline by Bruce,  is what
do we want for GCC. 

I don't agree with all of his views, but I do find that we ought to
make GCC useful.

-- Gaby


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