[cfe-dev] [llvm-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang

[Philip Reames via cfe-dev]

On 05/14/2018 12:07 PM, Friedman, Eli wrote:
> On 5/12/2018 9:23 PM, Philip Reames via llvm-dev wrote:
>> Fair warning, the following is a devil's advocate position, but it's 
>> also a serious question.
>>
>> Given the entire point of this flag appears to be bug mitigation, why 
>> not frame this as a sanitizer?  If we had a hypothetical 
>> -fsanitize=dereference which tried to catch dereferenced pointers 
>> derived from null, wouldn't that handle the case at hand?
>
> It's called "-fsanitize=null": it catches stuff like "x[3]" where x is 
> null. It's not quite complete; we don't check for arithmetic on a null 
> pointer.
>
> Yes, that would handle the situation in question, but putting implicit 
> null checks all over the place is pretty expensive; I don't think most 
> people would turn that on in production.
(again, knowingly playing devil's advocate)

But wouldn't it catch - during development, before release - the bug 
which motivates the desire for the mitigation?  If so, why worry about 
the mitigation?  Is the concern insufficient testing/coverage?

And alternatively, the performance overhead could be likely to be 
improved if someone wanted to spend some time doing so.   Between fully 
exploiting implicit null checks (support in tree today) and imprecise 
fault locations(*), I suspect the overhead could be made quite small.

* Terminology: "implicit null check" is simply constructing a load or 
store which is guaranteed to fault if the preceding null check would 
have failed.  "imprecise fault location" is allowing the failure to 
happen earlier or later in the execution so long as additional side 
effect is not visible.  If you're okay with earlier side effects not 
being visible, that opens up a lot of flexibility. Similar, allowing 
some side effects  (but not say, IO) does as well.

Philip