[LLVMdev] Should remove calling NULL pointer or not

[Philip Reames]

I've definitely seen code like the following in various production code 
bases:

namespace {
   bool global = false;
}
class Foo {
    void modify_global() { global = true; }
};

// usually, there's a layer of indirection (or two, or three) here
((Foo*)NULL)->modify_global();


Discussions on StackOverflow seem to clearly indicate that the above 
code is undefined.  Having said that, I have not tried to parse apart 
the actual spec on this one, so I'll leave that discussion to others.

If we do decide this is undefined, do we have a general policy on how to 
warn about, or under which optimization levels to enable, such 
optimizations?  If not, it would probably worth some discussion on what 
a general policy might look like.

Philip

On 11/6/13 4:36 PM, Yin Ma wrote:
>
> Hi,
>
> For a small case, that calls NULL pointer function. LLVM explicitly 
> converts
>
> It to a store because it thinks it is not reachable like calling 
> undefvalue.
>
> In InstCombineCalls.cpp:930
>
> I think it is not a right approach because calling null pointer function
>
> Will segfault the program. Converting to a store will make program pass
>
> Silently. This changes the behavior of a program.
>
> So we need remove the case if (isa<ConstantPointerNull>(Callee) at
>
> InstCombineCalls.cpp:918 and treat calling Null pointer reachable.
>
> How do you think? Is there any reason that we should convert
>
> a calling null pointer to a store?
>
> Thanks,
>
> Yin
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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