From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: craig AT jcb-sc.com Cc: dje AT watson.ibm.com, law AT cygnus.com, nik AT tiuk.ti.com, mrs AT wrs.com, gcc AT gcc.gnu.org, mark AT codesourcery.com, jbuck AT synopsys.com, craig AT jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 16 Sep 1999 23:13:00 -0000 Message-id: <199909170623.CAA19786@psilocin.gnu.org> References: <9909151630.AA36168@marc.watson.ibm.com> <19990915165930.15281.qmail@deer> X-SW-Source: 1999-09/msg00747.html So we can conclude that the expense (time and effort) needed to address this *one* issue is: - representative of what we're likely to expend over similar issues that *will* arise If subsequent issues are like this one, finding a way to improve the situatin will be fairly easy, but persuading certain people to accept an improvement may be difficult. But if people accept the principle of making small and easy efforts to keep old code working, subsequent issues will only involve the comparatively easy job of figuring out how to do that. 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 ;-). So people can either fix their code now, or fix it later. 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." having) to accommodate Merced or McKinley amounts to entertaining the same hopes, and therefore similar scaling of costs, as the Y2K problem. Compilers did not give warnings for Y2K problems, but we will make GCC give a warning for most of these problems. So these situations are hardly similar. 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: <199909170623.CAA19786@psilocin.gnu.org> References: <9909151630.AA36168@marc.watson.ibm.com> <19990915165930.15281.qmail@deer> X-SW-Source: 1999-09n/msg00747.html Message-ID: <19990930180200.F1yJA11gayDe65Wu1AcM1akEwOUhiCc8rjb8bNKe2DE@z> So we can conclude that the expense (time and effort) needed to address this *one* issue is: - representative of what we're likely to expend over similar issues that *will* arise If subsequent issues are like this one, finding a way to improve the situatin will be fairly easy, but persuading certain people to accept an improvement may be difficult. But if people accept the principle of making small and easy efforts to keep old code working, subsequent issues will only involve the comparatively easy job of figuring out how to do that. 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 ;-). So people can either fix their code now, or fix it later. 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." having) to accommodate Merced or McKinley amounts to entertaining the same hopes, and therefore similar scaling of costs, as the Y2K problem. Compilers did not give warnings for Y2K problems, but we will make GCC give a warning for most of these problems. So these situations are hardly similar.