Re: type based aliasing again

[Josh Stern <jstern@citilink.com>]

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