From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: artem AT duma.gov.ru Cc: gcc AT gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 16 Sep 1999 23:15:00 -0000 Message-id: <199909170626.CAA20026@psilocin.gnu.org> References: <00d301bf003f$5f862630$545a9090@uito-nt-server.duma.gov.ru> X-SW-Source: 1999-09/msg00750.html As was already mentioned here, with slight changes in gcc internals, invalid code will break, sooner or later, but inevitably. And all effort spent to implement your proposal will be in vain. "Invalid code will break" could mean either "some invalid code will break from time to time", or "all invalid code will certainly break". The former is true, but the latter is not. With my proposal, some of these invalid cases may break in the future. But chances are most of them never will break. That is one advantage. And the ones that do break, will most likely break a year or several in the future instead of now. That delay will give more time for today's current versions of various packages to be replaced with corrected code. (The warning would encourage people to make new versions which don't have these constructs in them.) Thus, even if a given case does someday break, the resulting user unhappiness will be less with my proposal. That is a second advantage. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: artem@duma.gov.ru Cc: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909170626.CAA20026@psilocin.gnu.org> References: <00d301bf003f$5f862630$545a9090@uito-nt-server.duma.gov.ru> X-SW-Source: 1999-09n/msg00750.html Message-ID: <19990930180200.KX-WTs_J870rfmIGGiyM0-Bg2WRdu0J0bRQysEV7nUA@z> As was already mentioned here, with slight changes in gcc internals, invalid code will break, sooner or later, but inevitably. And all effort spent to implement your proposal will be in vain. "Invalid code will break" could mean either "some invalid code will break from time to time", or "all invalid code will certainly break". The former is true, but the latter is not. With my proposal, some of these invalid cases may break in the future. But chances are most of them never will break. That is one advantage. And the ones that do break, will most likely break a year or several in the future instead of now. That delay will give more time for today's current versions of various packages to be replaced with corrected code. (The warning would encourage people to make new versions which don't have these constructs in them.) Thus, even if a given case does someday break, the resulting user unhappiness will be less with my proposal. That is a second advantage.