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

On Fri, Jan 02, 2004 at 06:11:50AM +0700, Robert Dewar wrote:
> Olivier Galibert wrote:
> >On Fri, Jan 02, 2004 at 12:08:30AM +0700, Robert Dewar wrote:
> >But any C compiler on a decently modern architecture that does not
> >have such an ordering would be considered broken, language lawyering
> >or not.  The era of near pointers is gone, and it's for the best.

> [...]
> Furthermore, compilers are definitely free to "break" this assumption.
> Indeed it is even valid for a compiler to use comparisons of this kind
> to provide aliasing information.

And users are free not to use such compilers, as always.  Personally I
don't see a real optimization reason to break pointer-pointer
comparisons.  What is the gain of not allowing known non-aliasing
pointers to be compared?  It would be annoying to make it impossible
to write memmove in C.

> The claim that any such compiler would be considered broken is an
> interesting one. Certainly I know that A. Stepanov considered this a
> serious restriction in C (interestingly, Ada does have general address
> arithmetic, and defines a total ordering on pointers, see the type
> System.Storage_Elements.Integer_Address).

Unofficially, that's what (unsigned long)pointer is too.

> It would be useful to document this set of assumptions that goes beyond
> what the standard guarantees, but is considered to be an implementation
> requirement for a given implementation anyway, and on which programmers
> are allowed to rely if they are using a particular implementation,
> e.g. GCC!

Sure.  What I see, personally, is a lot of reliance on the linear
memory model with unmapped page at zero, i.e. pointers are freely
comparable and are never binary zero.  Maybe a little more in C++ than
C too because map<> is an ordered container and not a hash and
pointers are sometimes useful as keys.  Plus, of course, the usual
issues with sizeof, sizeof(short)=2, sizeof(int)=4,
sizeof(long long)=8, sizeof(float)=4, sizeof(double)=8, 
sizeof(long)=sizeof(void *) being the usual assumptions.


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