This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patch to supress trailing missing initializer warnings


|   > I recall that I suggested to give the warning if less then
|   > three variables where left uninitialized.
| I think this is a poor design.  Either it gives the warnings or it does not,
| it should not be dependent on how many remaining uninitialized fields exist.

I already said it seemed "fuzzy" (kinda like 'what do you want? (On or off?)),
but if you think a bit longer about it, it is not that bad:

Consider case A: The way the patch was submitted
         case B: My proposal

Case B gives a warning is all situations that case A would
give a warning.  And the situations in which you would really
want a warning to be produced is a subset of the situations
in which case B gives a warning:

Program       Warning in   Warning in    Situations in which
Possiblities    case A       case B      you want a warning
  |               |            |              |
  |               |            |              |
  |               |            |              |
  |               |            |              |
  |               |            |              |
  |               |            |              |
  |               |            |              |
  |               |            |              |
  |                            |              | }
  |                            |              | } X
  |                            |              | }
  |                            |                 } Y
  |
  |
  |
  |
  |
  |
  |

I think that the situations in which you want a warning
but wouldn't get one with case A (X) is much larger then
the cases in which case B will give a warning while you
don't really care much about a warning (Y) (Apart from
the fact that it is better to give too much warnings in
this case then too less).

This shows that case B is *better*.

Fuzzy ok, but still better.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]