[LLVMdev] Should remove calling NULL pointer or not

Yin Ma yinma at codeaurora.org
Thu Nov 7 11:02:58 PST 2013


Hi John,

 

It seems the dereferencing a NULL pointer is undefined behavior but

Calling a function through a null pointer seems o.k.

 

If so , for this place, we need comment out the check.

 

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232

 

look at Notes from the October 2003 meeting.

 

Yin 

 

From: John Criswell [mailto:criswell at illinois.edu] 
Sent: Wednesday, November 06, 2013 6:28 PM
To: Yin Ma; 'llvmdev Dev'
Subject: Re: [LLVMdev] Should remove calling NULL pointer or not

 

On 11/6/13 6: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?


If calling a NULL function pointer yields undefined behavior (as defined by
the C/C++ standards), then the optimization is correct: since the behavior
is undefined, the compiler can change it as it sees fits.  In other words,
the compiler is not required to maintain "incorrect" behavior.

The remaining question, then, is whether the C/C++ standards consider
calling a NULL function pointer undefined behavior.  I suspect that it is
undefined behavior, but to be honest, I do not know for certain.

-- John T.






 

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/20131107/9bcdc80c/attachment.html>


More information about the llvm-dev mailing list