[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: New problems with gcc-2.8.0 based code - NOW FIXED!
From:       Paul Koning <pkoning () xedia ! com>
Date:       1997-12-30 23:35:58
[Download RAW message or body]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

 Paul> The alternatives are (a) to allow the compiler to do
 Paul> something it's not documented to do and that will cause
 Paul> subtle bugs, or (b) require the compiler to do something
 Paul> that it is documented to do, does no harm in any case, and
 Paul> avoids hairy bugs.  I think the right choice is pretty
 Paul> clear.

 Richard> First of all, there's no question that, at least in the
 Richard> short term, we have to make this change since there's code
 Richard> out there that depends on this behavior.

If I understand right, what you're saying is that the near-term change
should be to have input-only asms default to volatile.  Right?  Sounds
good.

 Richard> But the issue is what should the documented behavior *be*.
 Richard> In other words, how do we disambiguate the documentation.

Um, so are you saying then that you want the compiler to change to
match the documentation, and then later change both documentation and
compiler to behave once again the way they do in 2.7?

 Richard> There are *lots* of ways to write undefined C that can cause
 Richard> "subtle bugs" (things like "a[i++] * 2 + a[i]" are good
 Richard> examples of that).  We don't decide on the semantics of a
 Richard> language based on the fact that a programmer can use it
 Richard> improperly!

Actually, in many programming languages the likelihood of subtle bugs
IS a language design consideration.  Look at the Algol-68 report for
examples.  On the other hand, it's clear that C is an exception to
this.  But yes, if a feature has significant benefits, then the fact
that it can also create subtle bugs is usually not enough reason to
exclude it.

On the other hand, when considering a design decision where the issue
isn't forced by some standards committee, my inclination would be to
reduce the number of suble-bug-inducing features rather than
increasing it, ALL OTHER THINGS BEING EQUAL.  And no one has made an
argument so far that there is any BENEFIT to doing it the other way.
So, on one side of the balance there is a benefit (arguably small, but
a benefit nonetheless) and on the other side of the balance there is
nothing.  So the balance tips, doesn't it?

	paul

[prev in list] [next in list] [prev in thread] [next in thread]