<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 16, 2011, at 2:59 PM, Kostya Serebryany wrote:</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">I think, more generally, we should have a naming strategy for options<br>
controlling runtime checks. For the IOC checks, it would be useful to have<br>
fine-grained control </blockquote><div>FYI</div><div>For AddressSanitizer we may also need fine-grained control in the future. </div><div>-faddress-sanitizer-[no-]reads</div><div>-faddress-sanitizer-[no-]stack</div><div>
-faddress-sanitizer-[no-]globals</div></div></blockquote><br></div><div>Kostya and I discussed this offline, but I'd really really like to keep the number of public knobs to a minimum. The long term direction I'd like to see clang go is to have a small number of runtime checks (asan, ioc, array checks, whatever) and then have -fcatch-undefined-behavior turn on some reasonable set of them. Having a small number of knobs to tweak each of these runtime checkers is fine, but they should be a *small* number and easily explainable.</div><div><br></div><div>Flags with unitless magic numbers attached to them (like the gcc unroll thresholds) are highly frowned upon :)</div><div><br></div><div>-Chris</div><br></body></html>