From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Stern To: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Sun, 12 Sep 1999 11:20:00 -0000 Message-id: <199909121818.NAA13174@foshay.citilink.com> X-SW-Source: 1999-09/msg00466.html This is an interesting discussion. I'd like to throw out a couple of possible approaches which were not explicitly considered in the discussion. A1) The current tradition in gcc is to make -Wall a combination of other, individually specifiable, warning options. One possible approach to the current issue involves either changing this tradition, or making a new catch-all option -Wsuper, which can warn about additional constructs "which pertain to usage that we recommend avoiding and that we believe it is easy to avoid", with the idea that the type aliasing violations which can easily be detected using current technology would be warned about. The idea naturally would be to also warn about other likely problems which don't get their own individual warning option categoy, for whatever reason. Why consider this? A number of developers have basically expressed the position that all of the current proposals amount to either i. penalizing the (code performance of the) many for the sake of the few (ugly bit-twiddlings that break), or ii. providing a set of warnings which is not a natural category unto itself and which could lead to false assumptions about what is and is not detected by the compiler. This proposal would allow the compiler to add warnings about the most egregrious, easily detectable type aliasing problems, to the simplest and most convenient user-selectable warning option without a lot of semantic mess about what to call the category. Clearly, the overall appeal of the idea would very much depend on the extent to which the proposal would be helpful with other similar kinds of issues. A2) Add a new feature -CVersion X.YZ meaning the compiler attempts, on a best effort basis, to generate correct code for the dialect of C that yielded correct code with the older version X.YZ of the compiler (could be useful for C++ and other languages as well). If this feature is not implemented for version X.YZ, then either warn or exit with an error. The documentation for this feature would have be very emphatic about the fact that it is just provided on a best effort basis, and will not be 100% correct (even if the category of correctness for the feature was precisely defineable, which it isn't), and perhaps mention the alternative of -V X.YZ for 100% compatibility, providing version X.YZ is installed. Why consider this? Because a lot, perhaps a majority. of application programmers rely, implicitly or explicitly, on their compiler of choice as a guide to correctness standards for their language of choice. When that pseudo-standard changes from version to version of the compiler, and their code breaks, it causes inconvenience. If there is a lot of code that breaks and no maintainer for it, then it can cause a lot of inconvenience. This feature also has the potential to be very convenient from the vantage point of anyone doing tech support. - Josh From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Stern To: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909121818.NAA13174@foshay.citilink.com> X-SW-Source: 1999-09n/msg00466.html Message-ID: <19990930180200.iG5py7vLSdS6iVOg6gJQXV_LBQLLFRA8wp1Zhk_yXt4@z> This is an interesting discussion. I'd like to throw out a couple of possible approaches which were not explicitly considered in the discussion. A1) The current tradition in gcc is to make -Wall a combination of other, individually specifiable, warning options. One possible approach to the current issue involves either changing this tradition, or making a new catch-all option -Wsuper, which can warn about additional constructs "which pertain to usage that we recommend avoiding and that we believe it is easy to avoid", with the idea that the type aliasing violations which can easily be detected using current technology would be warned about. The idea naturally would be to also warn about other likely problems which don't get their own individual warning option categoy, for whatever reason. Why consider this? A number of developers have basically expressed the position that all of the current proposals amount to either i. penalizing the (code performance of the) many for the sake of the few (ugly bit-twiddlings that break), or ii. providing a set of warnings which is not a natural category unto itself and which could lead to false assumptions about what is and is not detected by the compiler. This proposal would allow the compiler to add warnings about the most egregrious, easily detectable type aliasing problems, to the simplest and most convenient user-selectable warning option without a lot of semantic mess about what to call the category. Clearly, the overall appeal of the idea would very much depend on the extent to which the proposal would be helpful with other similar kinds of issues. A2) Add a new feature -CVersion X.YZ meaning the compiler attempts, on a best effort basis, to generate correct code for the dialect of C that yielded correct code with the older version X.YZ of the compiler (could be useful for C++ and other languages as well). If this feature is not implemented for version X.YZ, then either warn or exit with an error. The documentation for this feature would have be very emphatic about the fact that it is just provided on a best effort basis, and will not be 100% correct (even if the category of correctness for the feature was precisely defineable, which it isn't), and perhaps mention the alternative of -V X.YZ for 100% compatibility, providing version X.YZ is installed. Why consider this? Because a lot, perhaps a majority. of application programmers rely, implicitly or explicitly, on their compiler of choice as a guide to correctness standards for their language of choice. When that pseudo-standard changes from version to version of the compiler, and their code breaks, it causes inconvenience. If there is a lot of code that breaks and no maintainer for it, then it can cause a lot of inconvenience. This feature also has the potential to be very convenient from the vantage point of anyone doing tech support. - Josh