From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: mrs@wrs.com Cc: gcc@gcc.gnu.org, jbuck@synopsys.COM Subject: Re: type based aliasing again Date: Thu, 09 Sep 1999 23:25:00 -0000 Message-id: <199909100634.CAA01815@psilocin.gnu.org> References: <199909090211.TAA03202@kankakee.wrs.com> X-SW-Source: 1999-09/msg00396.html 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: mrs@wrs.com Cc: gcc@gcc.gnu.org, jbuck@synopsys.COM Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909100634.CAA01815@psilocin.gnu.org> References: <199909090211.TAA03202@kankakee.wrs.com> X-SW-Source: 1999-09n/msg00396.html Message-ID: <19990930180200.QZQ4Gw_ttgdRyip60ckVUbqEA_ZeuwCuNKicNx9PYfI@z> 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.