<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 19, 2011, at 8:58 PM, Eli Friedman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy <<a href="mailto:shea@shealevy.com">shea@shealevy.com</a>> wrote:<br><font class="Apple-style-span" color="#006312"><br></font><blockquote type="cite">4. Are any behaviors undefined by virtue of not being specified in the<br></blockquote><blockquote type="cite">reference, or are all scenarios that lead to undefined behavior<br></blockquote><blockquote type="cite">explicitly identified as such?<br></blockquote><br>We really want to explicitly identify them all in the reference; if<br>you have a question about some specific case, please ask.<br></div></blockquote></div><div><br></div><div>However, there is a ton of stuff that's not explicitly identified today.</div><div><br></div>For example, consider a call to a function address bitcasted to a type<div>incompatible with the type of the function. Most of us around here intuitively</div><div>know this gets undefined behavior because we know how to think like a C</div><div>compiler. But LangRef doesn't discuss this. It doesn't even have a concept</div><div>of "compatible" types with which to discuss it.</div><div><div><br></div><div>What should the rules be? If we look through LLVM's source code, we</div><div>find that the inliner has code for smoothing over caller/callee mismatches.</div><div>However, we can't translate this logic into LangRef because it does things</div><div>that are impossible to do for non-inlined calls in most backends. If we</div><div>dig through every backend, we could come up with a minimal set of</div><div>functionality that could be broadly supported. However, this set would be</div><div>too minimal for clang, for example, which regularly bitcasts objc_msgSend</div><div>in ways that it knows will work, but only for non-obvious reasons.</div><div><br></div><div>You could spend weeks researching all the nuances of just this problem.</div><div>In practice, LLVM just doesn't worry about it. Problems like this tend to be</div><div>edge cases that don't cause trouble for most people most of the time.</div><div>However, you can find them all over the place if you go looking.</div></div><div><br></div><div>Dan</div><div><br></div></body></html>