Eli Schwartz <[email protected]> writes: > Does this mean you've conceded the point, and no longer think it is > written in C++?
No. > You are correct in reading my sentence, that is indeed what I said. > > Aside: you have reiterated "the behavior of the translator itself" over > and over again, but it hasn't been generally reiterated, or even iterated. Parse error. > Repeating this statement won't make it true. Before you say this, I suggest that you take some time to look at yourself in a mirror. > In fact, lots and lots and lots of programs do indeed operate such that > the documentation specifies how the program shall behave, and when the > program fails to behave in the manner in which it is documented to > behave, the program shall be fixed. > > We call these failures to behave according to the documentation, > > > Bugs. > > > Occasionally it is also called specification-driven development. > > ... > > In cases where the documentation says nothing at all, for good or ill, > the behavior of the program is undefined -- users cannot rely on it, for > they cannot know what is intended and what is not intended -- in this > case, the intended behavior must be defined, documented, and > implemented, and "the program currently does X" gets one vote out of > many and is not guaranteed to get its way. > > Very often in such cases the best user-serving thing to do is to define > the behavior as "shall not be used, and for legacy reasons if you use it > it will continue to do X but raise a warning telling you that you are > required to stop depending on it" and possibly even "it may disappear in > semver version YYY". Where is it written that GNU CC follows your so-called ``specification-driven development''? Here is an explanation from one of the original GCC developers. It discusses strict aliasing, but the same principles apply here: ([email protected]) My comment is similar to Mark's comment. Documentation, what can we document as working? We should not even try to document that these cases work. Documentation is what we do when we add a feature. I am not proposing this as a feature, just as a way to avoid evitable trouble for users. We should not even try to document a class of cases that are "supposed" to work, because I'm not saying these are "supposed" to work. We should just let them work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Anway, more questions from me than answers... Off hand though, if we can make the compiler generate `right' code in more cases, even if the users code is wrong, I think we should probably do it. In C, we cannot divide all user code into "right" and "wrong" in this kind of simple way, and certainly not based on the ISO standard. That standard is just the decisions of a certain committee (which I was a member of) about what cases conforming compilers should commit to support. We must not let ourselves start thinking that C code is "wrong", just because it is not conforming ISO C code. C programs use many cases that are not conforming, but do work. This will be true for as long as C is used, because changing it would require major changes in the C language. From time to time, there is a real *need* to make some of these cases stop working, for the sake of some benefit that users want. When this happens, we should do it; the user community will accept it, because they will see that it is being done for their sake. Some will grumble, but the users who appreciate the benefits will convince them. But when there is no *need* to break these cases, when we can keep them working fairly easily, we should keep them working. If we break them unnecessarily, we invite the legitimate anger of the users. and another ([email protected]): However, I have a rather serious objection: it means that users cannot tell whether their code is valid, even according to the GCC rules, without knowing the internals of the compiler. This has always been true. It is true in the current version of GCC with regard to aliasing, even when -fstrict-aliasing is used. It is part of the nature of C. The goal of trying to avoid it is unrealistic and misguided; it can't be done. So this cannot be a valid reason to reject a change. The compiler should continue to aggressively break code that misbehaves in this way. This proposes to break users' code, just to bully them into changing it. That is a callous and harsh attitude towards the users of GCC. No wonder users are angry. They know that the problems are not due to necessity, but due to callous disregard for them. We cannot do everything all users want, and sometimes a maintainer has to say no to users. "You cannot please everyone," as the saying goes. There are many kinds of reasons which can sometimes be good reasons to say no. But maintainers should always say no reluctantly--never eagerly. We should never aggressively cause trouble for users today, just because someday it might be necessary. That is like amputating limbs because someday they might be crushed. This treatment of users brings shame on the GNU Project. I ask everyone therefore not to suggest that we should treat users this way. > Sound familiar? A bit like GCC triggering a warning, telling you that > what you're doing is bad and should not be relied on? A diagnostic message is supposed to inform me of a diagnosis by the translator. The severity of the diagnosis, is, as always, up to the user to decide, as long as enough information remains for translation to continue. > But GCC isn't dropping support for it in semver version anything, just > guarding its use behind an opt-in flag. Which is liable to disappear in the future, as many have before it.
