llvm dev - Jul 2012 - [LLVMdev] proposal for exploiting undefined behavior much more aggressively

http://blog.regehr.org/archives/761

Thanks,

John

On Jul 26, 2012, at 9:58 AM, John Regehr wrote:
> http://blog.regehr.org/archives/761
It's an interesting post, but I'd like to point out that it is a
non-goal for the project to be actively hostile to users of the compiler.  :) 
It is useful to have debugging tools for people who really care, but
"exploiting" undefined behavior just for the sake of breaking code is
a non-goal.

A specific example is code like this (which is quite common):

int ftoi(float F) {
  return *(int*)&F;
}

This is a violation of the C spec, due to type-based aliasing issues (the right
approach is to use a union).  That said, we go out of our way to not break this
sort of idiom, because it is obvious to the compiler and actively hostile to a
widely used pattern in dusty deck code.

-Chris

> I'd like to point out that it is a 
> non-goal for the project to be actively hostile to users of the 
> compiler.  :)
I like that in a compiler :)

John

On Thu, Jul 26, 2012 at 3:41 PM, Chris Lattner <clattner at apple.com>
wrote:
> On Jul 26, 2012, at 9:58 AM, John Regehr wrote:
> > http://blog.regehr.org/archives/761
>
> It's an interesting post, but I'd like to point out that it is a
non-goal
> for the project to be actively hostile to users of the compiler.  :)  It is
> useful to have debugging tools for people who really care, but
"exploiting"
> undefined behavior just for the sake of breaking code is a non-goal.
>
Also, as a bit of a teaser, I think Richard Smith is going to be looking
into providing much more extensive optional *checking* of undefined
behavior. Essentially, '-fcatch-undefined-behavior' may grow some
serious
teeth. This should allow users to check their code fairly aggressively for
UB but not needlessly punish code or those debugging code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120727/44738c57/attachment.html>