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

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.

Well it is interesting to note that this restriction in C has been there for ever, long before the issue of "near pointers" arose with the x86. It is true that this kind of ordering was indeed broken by segmented pointers, but it is a bit worrisome to assume that no such issues will arise in any other situations.

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.

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

The whole issue of semantic extensions not in the standard but which
all programmers assume and which therefore all compilers have to
properly implement is an important one for any language. A good
example of this was Fortran-66's insistence on a non-persistant
model of DATA storage that allowed a stack model of allocation
rather than static allocation. The Burroughs 5500 Fortran compiler
took advantage of this, and was correct to the standard, but was
unusable in practice, since Fortran programmers of the era routinely
assumed static storage allocation.

So the interesting question raised by the quoted paragraph above is
"considered by whom?." Certainly when I write C I am careful NOT to
assume this ordering property since I know it is not guaranteed by the
language, and for example comparing an address two elements beyond the
end of an array with the address of the last element of the array is
definitely "wrong".

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!

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