From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: craig@jcb-sc.com Cc: dje@watson.ibm.com, law@cygnus.com, nik@tiuk.ti.com, mrs@wrs.com, gcc@gcc.gnu.org, mark@codesourcery.com, jbuck@synopsys.com, craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909180527.BAA21187@psilocin.gnu.org> References: <9909151630.AA36168@marc.watson.ibm.com> <19990915165930.15281.qmail@deer> <199909170623.CAA19786@psilocin.gnu.org> <19990917081937.24996.qmail@deer> X-SW-Source: 1999-09n/msg00775.html Message-ID: <19990930180200._ztA6nwArA3kjAYngMkt5dBG5FaT_BriyQe-c1PgoCA@z> You have written a long message, as you often do. It contains a number of points that I disagree with, but I don't have time to respond to them all. So I have chosen the few that seem most important. >I notice a pattern that people arguing against concern for the users >tend to exaggerate the situation in this particular way: they change >"some of this code may break, may need to be changed" into "all of >this code will break, will need to be changed." I didn't say that. But, for the purposes of assessing these issues, that's how people maintaining their code should *think*. It is a mistake to judge everything by worst-case costs instead of likely costs. That leads to decisions that increase the expected costs. In situations like this, it leads to a pattern of skewed judgement, consistently being too harsh to users. I wonder if some of the other people who have argued for harshness on this issue are also making a conscious assumption of calculating costs based on the worst case for kindness. They are not assuming the worst case for harshness! >In effect, your argument is that this proposal is a bad idea because >Craig Burley and others will spend time arguing against it. I do not >think that the proposal can be held responsible for that ;-). If you view it that way, especially as a spokesman for the GNU project, which controls GCC, you are saying that the only real cost, in terms of added complexity, to being willing to consider changing the compiler to better accommodate broken code is that there will be some people who openly disagree with that policy and/or with the specifics of the proposal. Yes. Once people accept the principle of doing this kind of accommodation, actually doing it will be easy. The idea is that you only spend a limited amount of time looking for a solution, and only do something if you find an easy way. This always has to be easy. The only thing that is hard is when people argue, as you are doing, against the very idea of accommodation. So please don't do that. In effect, you are telling me that if I don't want GCC to become even more complicated and hard to maintain than necessary, or have bugs fixed in it less speedily due to long-drawn-out discussions like this, I should no longer participate in discussions like this, except perhaps to grunt things like "okay by me" or "no way". Those thoughts are yours, not mine. I am just asking you and others to stop arguing for a policy of harshness toward the user--to stop arguing against the very idea of trying to accommodate old undefined code. If you don't want GCC to be more complicated or for the work to go slower, then you share my feelings on that issue. That's why I looked for a simple change that is clearly correct and will be easy to implement. In the future, I would like the GCC developers to look for such changes, because this is what the GNU Project needs GCC to do. this discussion is that there have been quite a number of statements made that are either incorrect in fact or incomplete in portraying cost/benefit analyses vis-a-vis this issue. Since *most* of those statements have been made to promote accommodation, I have seen a regular pattern of exaggeration in the messages arguing for harshness. The worst always can happen, but it is very unlikely to happen always. Programmers should view bugs in their code like termites. I think you are partly right, but not entirely, because you are demanding a strictness that is more trouble that it's worth for many projects, and is also more work than most free software developers can manage to do. Fortunately, a somewhat more relaxed approach works pretty well. Be that as it may, that question is a side issue. You are talking about programmers running GCC on code that they are developing. Those are just some of the users of GCC. Only some of the people running GCC are running it on code they understand, or could attempt to debug. We must not make GCC decisions with only those people in mind. But, I believe the analysis for GCC *itself* is *much* simpler: conform to the pertinent ANSI/ISO standards, etc. GCC does conform to these standards, when used with the proper set of options. However, technical standards are not a moral authority. The GNU Project policy is that we pay close attention to official standards, but we don't slavishly obey them. In this case, the issue is not even whether GCC complies with the C standard. It concerns the behavior of GCC in a case which the C standard does not specify.