<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Tue, Jun 19, 2012 at 10:36 AM, Matthieu Monrocq <span dir="ltr"><<a href="mailto:matthieu.monrocq@gmail.com" target="_blank">matthieu.monrocq@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jun 19, 2012 at 7:01 PM, Chris Hall <span dir="ltr"><<a href="mailto:chris.hall.list@highwayman.com" target="_blank">chris.hall.list@highwayman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chandler Carruth wrote (on Tue 19-Jun-2012 at 17:50 +0100)<br>
<div>><br>
> On Tue, Jun 19, 2012 at 1:20 AM, Jay Foad <<a href="mailto:jay.foad@gmail.com" target="_blank">jay.foad@gmail.com</a>> wrote:<br>
</div>....<br>
<div>>>  #define N 8<br>
>>  const int a[N] = { 3, 1, 4, 1, 5, 9, 2 };<br>
>> warning: some but not all array elements initialised<br>
</div>...<br>
<div>> Maybe someone has clever ideas about how to syntactically differentiate<br>
> between these two use cases?<br>
<br>
</div>  const int a[N] = { ..... } __attribute__((all_explicitly_initialised))<br>
<span><font color="#888888"><br>
Chris<br>
</font></span><div><div><br><br></div></div></blockquote></div></div><div>Would a heuristic be acceptable ?<br><br>If the number of initializer is in [.9 * N, N) then it looks likely it is a bug. The .9 factor could probably benefit from some tuning, maybe as low as .5 would pass.</div>
</div></blockquote><div><br></div><div>I really dislike this style of diagnostic, because it's essentially impossible to tell innocent users what to do when the warning fires on their correct code.</div><div><br></div>
<div>user: Why am I getting this warning? My code is correct!</div><div>me: Well, we have a heuristic to try to detect when there is a bug, and it triggers on your code.</div><div>user: But my code doesn't have a bug. The standard says right there that this is a supported use case.</div>
<div>me: I understand, but there is code that looks *exactly* like your code that is in fact a bug.</div><div>user: So what rule do I use when writing code so I don't tickle this warning when my code is correct, but I get the warning when it has a bug?</div>
<div>me: ...</div><div><br></div><div>I have no answer for that last question. I can't say '0.9 * N' for lots of reasons. We would change it to 0.8 at some point, users can't count past 10, and they certainly can't multiply or divide, and so the rule wouldn't help. I can't say "follow the standard" because the standard directly contradicts this warning. I can't realistically say "always initialize every element" because often that's either impractical, impossible, or just plain poor style. (Hence the standard allowing this partial formation...)</div>
<div><br></div><div>When we're designing warnings that try to catch bugs, we need to focus on getting the warning into a state that is easier to explain and cope with for our users. For example:</div><div><br></div><div>
1) A warning that is *always* a bug in the code is easy: the user can't really complain, their code is simply wrong.</div><div>2) A warning that directs innocent users to some alternate syntax which hase equivalent semantics but is more explicit / clear / less bug-prone.</div>
<div><br></div><div>#2 is really hard to get right, and we should be overly conservative in employing it. Here are a few cases where I think we do a good job here:</div><div>- Demanding explicit '()'s to group mixed '&&' and '||' operations, due to poor understanding of their precedence</div>
<div>- Warning about functions declared at block scope unless they are explicitly marked with 'extern' due to their confusion with declaring a variable and calling its constructor (most vexing parse, etc).</div><div>
- Warning when a literal is converted to an unexpected type, such as converting 'false' to a null pointer.</div><div><br></div><div>In all of these cases, there is a significantly more clear way to express the intent of the programmer, and we have a very large body of evidence that these warnings almost unilaterally fire on buggy or incorrect code based on the experience turning them on across large code bases. Just having one of these isn't enough, it's important to have both. It's also important to be able to argue for the more clear formation through the presence of *bugs*, not through a stylistic or aesthetic preference.</div>
</div></font></div>