Re: patch to supress trailing missing initializer warnings

[Nathan Sidwell <nathan at cs dot bris dot ac dot uk>]

Carlo Wood wrote:
> 
> 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:
No, I think this fuzziness would be annoying -- the user might/might not
expect a warning in cases where it was/wasn't given.

For incrementally changing code (i.e. during development) Carlo's
proposal would get really awkward. This is happening to me at the
moment. I have a structure which, as my program develops I have to add a
new field to, which gets NULL inited and then holds random stuff during
execution. (i.e. v1 in the following).
	struct A { char const *name; ...; int v1;};
In a static table of these things, I have to init v1 to zero, to remove
the warning.
	static A thing = {"wibble", ..., 0};
Now, I find I need to add v2, for the same kind of thing. With my patch,
I don't have to change the definition of thing, it already has a
trailing zero init. With Carlo's suggestion I must add another zero.

Now iterate this a few times and you've got v1 ... v6. Each time a new
one was added, all the the inititializers needed amending under Carlo's
scheme. But the final result could be ok as the original initializer
which just did v1. Later reading of the code might confuse one as to why
you've explicitly inited all the trailing values to zero.

Carlo's example in another email about an array initializer is not
addressed by this warning or patch, and hence not relevant to this
discussion (the check is only for class member initialization).

I also believe your analysis of the problem to be incomplete. Let me try
you with this one,

Case A - no detection at all (i.e. warning is disabled)
Case B - the way egcs is now (i.e. warn about every uninited member)
Case C - the patch behaviour when it's not in mode B (warn if last is
not NULL)
Case D - Carlo's proposal.

For any particular warning there can be false positives (spuirious
warnings) and false negatives (missed warnings). Obviously we want to
minimize these. However, it is my contention that we want to work really
hard minimizing the false positives. Hence 1 false positive is
equivalent to more than one false negative.

Here's a little figure to show what I think the relative behavious of
the schemes are. Each column is a particular code case. The columns are
not equally weighted
	         1234567
	ideal    nnnnppp
	Case A   nnnnNNN
	Case B   nPPPppp
	Case C   nnnPNNp
	Case D   nnPPNpp

N == false Negative, P = false positive, n = negative, p = positive

The figure shows that case B gives the most false positives, but catches
all the true positive (I don't think it can give a false negative). Case
C gives the least false positives, but does give more false negatives
than case D. Now are enough cases in column 6 to outweigh the annoyance
of cases in column 3? If so we should use method D, if not the method C.

The only hard evidence I have is my particular circumstance, where it is
very much the case that column 6 has negligible size and column 3 does
not.

probably a far too long an analysis of such a minor issue! Oh well, I've
written it now.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk