[cfe-dev] RFC: Nullability qualifiers

[Douglas Gregor]

> On Mar 2, 2015, at 3:41 PM, Dean Sutherland <dfsuther at yahoo-inc.com> wrote:
> 
> 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?

This kind of decision is really up to the owner of that API. If she believes that her API shouldn’t make it easy to introduce this form of security problem, she can mark it as “__nonnull” and put in some defensive code to either fail softly or emulate prior behavior. Clients that pass a null value will start to see warnings that there is an issue.

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

We’re almost there in Clang, although I doubt that I personally will have time any time soon to work on addressing the issue of type sugar flowing through template specializations. I don’t think it’s fundamentally that hard to do, and beyond that I expect that we’ll see a long tail of small issues where we’re not maintaining type sugar everywhere.

	- Doug

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