<div class="gmail_quote">On Thu, Feb 3, 2011 at 6:35 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":v43">Since several checks in clang are bundled under the -Wuninitialized flag, there may be some argument to splitting these under separate flags.<br>
<br>
Is there a general desire to do this?  If so, why?<br></div></blockquote><div><br></div><div>My primary desire to allow controlling this with more granularity is to help ease and stage the rollout of these types of checks on a very large codebase.</div>
<div><br></div><div>However, I don't think having such granularity is actually in conflict with this principle, which I agree on:</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":v43">My personal feeling is that things should be kept simple: keep a single -Wuninitialized flag that turns on all uninitialized variables checking.</div></blockquote><div><br></div><div>I think we can have a pretty reasonable setup using the existing diagnostic group infrastructure:</div>
<div><br></div><div>- one flag that turns all uninit checking on (or off with the no-... variant)</div><div>- several flags that turn specific types / strategies on (or off with the no-... variant)</div><div>- last flag (of either form) wins</div>
<div><br></div><div>This would allow patterns like "-Wuninitialized -Wno-foo-uninitialized" to get everything except a specific feature that doesn't work for a project or codebase, and "-Wno-uninitialized -Wfoo-uninitialized" to get just one type of warning that a project cares about.</div>
<div><br></div><div>Most users should focus on the simple big switch, and never care about the details.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":v43">Users can then either suppress the warning by initializing their variables (which I argue is cheap and overall good for code cleanliness) or use pragmas to shut up the warning entirely in regions of their code.  The latter may be a gross solution, but it is there for those who want it.</div>
</blockquote></div><br><div>The problem in some cases isn't how you silence the warning, but the necessity of code changes to do so. That's why I'm suggesting some flag based controls.</div><div><br></div><div>
Something else I'd like to explore (perhaps on a different thread) is whether we could devise a more friendly syntax for a user to explicitly acknowledge the lack of initialization on a variable as intentional. Pragmas are really gross, and not a precise instrument. I'm imagining:</div>
<div><br></div><div><font class="Apple-style-span" face="'courier new', monospace">  HugePODStruct foo [[uninitialized]];  // Performance sensitive!</font></div><div><br></div><div>as something that can be used in those very rare cases where it matters, without polluting the code with pragmas, and loosing the checking of other variables that aren't so sensitive.</div>
<div><br></div><div>FWIW, I'm willing to contribute patches toward both proposals made here if we can agree on exactly what they should look like.</div>