This is the mail archive of the
mailing list for the GCC project.
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
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.