Re: Warning elimination patches in cp/call.c

[Jeffrey A Law <law at cygnus dot com>]

  In message <199803092308.SAA28344@franck.Princeton.EDU>you write:
  > Does this construct bother anyone else other than me?  In some cases,
  > it is certainly the correct behavior (when a small number of cases are
  > handled explicitly, and the rest should be ignored) but if added too
  > often, it makes the warning it fixes completely useless, since that
  > particular switch() will no longer _ever_ warn about unhandled cases.
  > I'd rather see patches that add "case <unhandled enum> : break" after
  > determining that the value in question really shouldn't be handled.
  > "default: break" should only be added when the number of "case x :
  > break" statements gets large.
This is an enormous amount of work, not to mention flat out impossible
since we allow language front ends to make their own tree nodes.  It's
also unmaintainable -- consider how much code has to change every
time we want to add a new RTL or TREE code.

Additionally, from my experience with gcc the default cases were
omitted in the past for those cases we know are "don't care"
conditions.

Yes, there may be a few that should be aborts.  But the behavior with
the default: break case matches the current behavior -- which is
what I think we want to do unless we know its wrong (as has been
the case for some of the suggested paren warning fixes).

The goal of fixing warnings right now is to get rid of most of the
noise so that the warnings which are more likely to represent real
problems can be identified and dealt with.  The patches to use
default:break work towards that goal and (IMHO) don't make it any
more difficult to find the few cases that should be aborts.


jeff