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

Bruce Korb wrote:

No; 6.2.4#2 says that "The value of a pointer becomes indeterminate when
the object it points to reaches the end of its lifetime.";

That's nice. Were there a compiler that were to take that clause and use it to destroy the semantics of a program, I would expect and actually hope that compiler would disappear and never see the light of day again.

Well if we took the union of all C programmers non-justified-by-the-standard expectations and required
compilers to satisfy all of these, we would be really
in a mess. So we have to be very very careful in agreeing to
such claims. Yes, I think it is reasonable to have things on
the list, and that arises in the case of Ada (which is much
more concerned about portability in practice than C, for
example, all Ada programmers know and read the Ada standard).

I am reaching the conclusion that too much of
the standard was written by lawyers out of touch with real programming.

On the contrary, there are conflicting goals here. Many "real" programmers are VERY concerned about performance, and we want to
be careful about damaging optimization.

Take pointer comparison. C has *never* allowed general pointer
comparison. The original description by K&R is quite clear on
this point. Requiring general pointer comparison to work is indeed
very damaging on some architectures. Really all C programmers should
know C and know the rules.

However, it is certainly true that many programmers expect general
pointer comparison to work, and are even surprised at this late
date (see prev messages in this thread) that C does not define
this to work.

Now it is perfectly legitimate to make a pragmatic decision that
enough programs depend on this "wrong" assumption to make it worth
while having the compiler guarantee that pointer comparison will
work. This has to be balanced against possible damage to optimized
code. In this particular case, my guess is that the impact on
optimization is insignificant. One rule here is not to accept
people's vague claims and guesses as to the value of any
particular optimization. Compiler writers are *notorious* when
it comes to being over-optimistic about the value of specific
optimizations -- in practice the rule I have often stated
"All optimizations are disappointing", is a good approximation
of reality.

Given the critical importance of general pointer comparison from
a semantic point of view, I suspect the balance is to make sure
that this works.

As for comparing old pointers from realloc, I am less convinced

a) it is hard to believe many programs are affected
b) the value from a semantic point of view of this feature is marginal

On the other hand, the impact on optimization is negligible. What
might be valuable is using some kind of trap pattern to catch what
might well be a bug.

I certainly hope GCC does not go down the path of, "The strictest
reading of the standard allows us to do this counter-intuitive thing.

What is counter-intuitive to one C programmer is to another C programmer who knows the standard obviously correct behavior. For example there are still C programmers around who think that C actually guarantees wrap around arithmetic for signed integer arithmetic, but one would hope that most C programmers know this is not the case.

and thereby let us optimize into oblivion some more code."  GCC
needs to try to be useful instead.

Performance is useful to many people. This is all about utility from a purely pragmatic point of view.

Maybe it is too late.

Well it's never too late to improve performance. Of course improvements in performance at the expense of wiping out too much legacy code even if that legacy code is "wrong" may be dubious. We certainly have ended up implementing a few dubious features in GNAT because we know that legacy code (e.g. from the old VADS compilers) tends to make "bad" assumptions.

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