<html><body><div style="color:#000; background-color:#fff; font-family:garamond, new york, times, serif;font-size:16px"><div id="yui_3_16_0_1_1425320575162_168947" dir="ltr">What a very good idea! Strong support for expressing and checking intent regarding potential nullability can clearly help us all right more reliable programs. I have a few questions, though.</div><div id="yui_3_16_0_1_1425320575162_180965" dir="ltr"><br></div><div id="yui_3_16_0_1_1425320575162_181211" dir="ltr">* Consider LoadHTMLString:BaseURL: from the UIWebView class. Providing a null pointer for the BaseURL is clearly *legal*. It even has a defined meaning, which is "don't bother to enforce the same origin policy for this content." So the BaseURL argument is nullable in terms of the analysis you propose above. So far, so good. Sadly, turning off the "same origin policy" is nearly always a serious security bug. Permitting a null pointer in this context is extremely likely to be wrong; it probably represents a bug 999 times out of 1000 uses. (I'd claim it was *always* wrong, but someone at some point decided it was a feature worth supporting and documenting. And I have seen a very few unit tests where passing a null pointer for the BaseURL was arguably OK). Do you intend to address this kind of "legal, but virtually certain to be wrong" usage, or is that out of scope?<br></div><div id="yui_3_16_0_1_1425320575162_183619" dir="ltr"><br></div><div dir="ltr" id="yui_3_16_0_1_1425320575162_168948">* Based on your discussion of type system impact, I'm sure you are all well aware that the compiler support for "maintaining type sugar through semantic analysis" needed to make this proposal work is *almost* enough to support a full "plug-able type system" similar to what's available in recent versions of Java. Do you have any plans to address the missing pieces? Being able to support pluggable type information more broadly (while continuing to guarantee that adding such qualifiers/attributes/however-it's-expressed would have zero impact on generated code) would enable all sorts of interesting analyses. A few examples that spring to mind include compile-time enforcement of physical unit compatibility, various protocol-level checks (type states, a la Bierhoff & Aldrich), and many more. When last I investigated this question (about a year ago), the limitation regarding templates (your [6]) was the only significant missing piece. Closing that gap would greatly reduce the difficulty (and project risk) of implementing such analyses.<br></div><div id="yui_3_16_0_1_1425320575162_180046" dir="ltr"><br></div><div id="yui_3_16_0_1_1425320575162_180285" dir="ltr">Dean F. Sutherland</div><div id="yui_3_16_0_1_1425320575162_187752" dir="ltr"><br></div><div class="qtdSeparateBR"><br><br></div><div id="yui_3_16_0_1_1425320575162_169662" style="display: block;" class="yahoo_quoted"> <div id="yui_3_16_0_1_1425320575162_169661" style="font-family: garamond, new york, times, serif; font-size: 16px;"> <div id="yui_3_16_0_1_1425320575162_169660" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_1_1425320575162_169664" dir="ltr"> <font id="yui_3_16_0_1_1425320575162_169663" face="Arial" size="2"> On Monday, March 2, 2015 1:22 PM, Douglas Gregor <dgregor@apple.com> wrote:<br> </font> </div> <br><br> <div id="yui_3_16_0_1_1425320575162_172611" class="y_msg_container"><div id="yiv5135322564"><div id="yui_3_16_0_1_1425320575162_172610">Hello all,<div id="yui_3_16_0_1_1425320575162_172609" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_172612" class="yiv5135322564">Null pointers are a significant source of problems in applications. Whether it’s SIGSEGV taking down a process or a foolhardy attempt to recover from NullPointerException breaking invariants everywhere, it’s a problem that’s bad enough for Tony Hoare to call the invention of the null reference his billion dollar mistake [1]. It’s not the ability to create a null pointer that is a problem—having a common sentinel value meaning “no value” is extremely useful—but that it’s very hard to determine whether, for a particular pointer, one is expected to be able to use null. C doesn’t distinguish between “nullable” and “nonnull” pointers, so we turn to documentation and experimentation. Consider strchr from the C standard library:</div><div id="yui_3_16_0_1_1425320575162_172614" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_179308" class="yiv5135322564"><div id="yui_3_16_0_1_1425320575162_179307" class="yiv5135322564"><font id="yui_3_16_0_1_1425320575162_179541" class="yiv5135322564" face="Menlo"><span id="yui_3_16_0_1_1425320575162_179540" class="yiv5135322564Apple-tab-span" style="white-space:pre;"> </span>char *strchr(const char *s, int c);</font></div></div><div id="yui_3_16_0_1_1425320575162_179309" class="yiv5135322564"><br class="yiv5135322564"></div>[BIG SNIP]<div id="yui_3_16_0_1_1425320575162_179572" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_172919" class="yiv5135322564"><div id="yui_3_16_0_1_1425320575162_179571" class="yiv5135322564"><b id="yui_3_16_0_1_1425320575162_179570" class="yiv5135322564">Type System Impact</b></div><div id="yui_3_16_0_1_1425320575162_172918" class="yiv5135322564">Nullability qualifiers are mapped to type attributes within the Clang type system, but a nullability-qualified pointer type is not semantically distinct from its unqualified pointer type. Therefore, one may freely convert between nullability-qualified and non-nullability-qualified pointers, or between nullability-qualified pointers with different nullability qualifiers. One cannot overload on nullability qualifiers, write C++ class template partial specializations that identify nullability qualifiers, or inspect nullability via type traits in any way. </div><div id="yui_3_16_0_1_1425320575162_172920" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_172929" class="yiv5135322564">Said more strongly, removing nullability qualifiers from a well-formed program will not change its behavior in any way, nor will the semantics of a program change when any set of (well-formed) nullability qualifiers are added to it. Operationally, this means that <i id="yui_3_16_0_1_1425320575162_172932" class="yiv5135322564">nullability qualifiers are not part of the canonical type</i> in Clang’s type system, and that any warnings we produce based on nullability information will necessarily be dependent on Clang’s ability to retain type sugar during semantic analysis.</div><div id="yui_3_16_0_1_1425320575162_172931" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_172923" class="yiv5135322564">While it’s somewhat exceptional for us to introduce new type qualifiers that don’t produce semantically distinct types, we feel that this is the only plausible design and implementation strategy for this feature: pushing nullability qualifiers into the type system semantically would cause significant changes to the language (e.g., overloading, partial specialization) and break ABI (due to name mangling) that would drastically reduce the number of potential users, and we feel that Clang’s support for maintaining type sugar throughout semantic analysis is generally good enough [6] to get the benefits of nullability annotations in our tools.</div></div><div id="yui_3_16_0_1_1425320575162_172924" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_172925" class="yiv5135322564">Looking forward to our discussion.</div><div id="yui_3_16_0_1_1425320575162_172926" class="yiv5135322564"><br class="yiv5135322564"></div><div id="yui_3_16_0_1_1425320575162_172927" class="yiv5135322564"><span class="yiv5135322564Apple-tab-span" style="white-space:pre;"> </span>- Doug (with Jordan Rose and Anna Zaks)</div><div id="yui_3_16_0_1_1425320575162_187524">[SNIP]</div><div id="yui_3_16_0_1_1425320575162_187523"><br></div><div id="yui_3_16_0_1_1425320575162_186814" class="yiv5135322564">[6] Template instantiation is the notable exception here, because it always canonicalizes types.</div><div id="yui_3_16_0_1_1425320575162_186813" class="yiv5135322564"><br class="yiv5135322564"></div><div class="yiv5135322564"></div></div></div><br><div id="yiv5135322564"><div><div class="yiv5135322564"></div></div></div><br>_______________________________________________<br>cfe-dev mailing list<br><a ymailto="mailto:cfe-dev@cs.uiuc.edu" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br><br><br></div> </div> </div> </div> </div></body></html>