[cfe-dev] RFC: Nullability qualifiers

[Dean Sutherland]

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.
* 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?

* 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.

Dean F. Sutherland


     On Monday, March 2, 2015 1:22 PM, Douglas Gregor <dgregor at apple.com> wrote:
   

 Hello all,
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:
 char *strchr(const char *s, int c);
[BIG SNIP]
Type System ImpactNullability 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. 
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 nullability qualifiers are not part of the canonical type 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.
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.
Looking forward to our discussion.
 - Doug (with Jordan Rose and Anna Zaks)[SNIP]
[6] Template instantiation is the notable exception here, because it always canonicalizes types.


_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150302/f0978ecc/attachment.html>