<div class="gmail_quote">On Tue, Nov 15, 2011 at 9:02 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Tue, Nov 15, 2011 at 8:51 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div>On Tue, Nov 15, 2011 at 8:46 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div><div><br></div></div></div><div>See <a href="http://clang.llvm.org/docs/LanguageExtensions.html#feature_check" target="_blank">http://clang.llvm.org/docs/LanguageExtensions.html#feature_check</a> -- it should be completely compiler neutral. </div>



</div></blockquote><div><br></div></div><div>So, the user code will have to look like this? </div><div><br></div><div>#ifndef __has_feature</div><div># define __has_feature(x) 0</div><div>#endif</div><div>...</div><div><br>


</div>
<div>#if __has_feature(address_sanitizer)</div><div>..</div><div>#endif</div></div></blockquote><div><br></div></div><div>I would hope it could be simplified as:</div><div><br></div><div>#if defined(__has_feature) && __has_feature(address_sanitizer)</div>


<div>...</div><div>#endif</div></div></blockquote><div><br></div></div><div>What is the status of __has_feature? </div><div>Is it a pure clang extension? </div><div>Is it suggested for standardization? </div><div>If other compilers are not going to accept/implement __has_feature I afraid that the user code will actually have to look like this:</div>

<div><br></div><div>#if defined(__has_feature) && __has_feature(address_sanitizer)</div><div># define ADDRESS_SANITIZER 1</div><div># elif defined(__gcc_analog_of_has_feature) && __gcc_analog_of_has_feature(address_sanitizer)</div>

<div># define ADDRESS_SANITIZER 1</div><div># elif defined(__msvc_analog_of_has_feature) && __msvc_analog_of_has_feature(address_sanitizer)</div><div># define ADDRESS_SANITIZER 1</div><div>#endif</div><div><br></div>

<div>#ifdef ADDRESS_SANITIZER</div><div><code></div><div>#endif</div><div><br></div><div>Argument 'can be easily implemented in gcc' does not work. </div><div>We need something like 'will most likely be accepted by gcc' for any value of 'gcc'.</div>
</div></blockquote><div><br></div><div>Looping in Diego who seems most likely to both have insight into what GCC would do here, and know others who would be interested in this discussion.</div><div><br></div><div>I would very much like to see __has_feature (and its ilk) become widely available specifically to ease the problem of collisions between existing tokens and preprocessor macros, and to give some more semantic clarity to what exactly people are testing.</div>
<div><br></div><div>I don't think 'ADDRESS_SANITIZER' being defined, or even '__ADDRESS_SANITIZER' being defined really helps the problem you mention above. If we keep making up arbitrary systems for marking features as on or off, any project striving for broad compatibility with many different compilers will *have* have have piles of if-def code like you describe. Moving (even one feature) toward a systematic pattern for detecting and enabling functionality when available seems like the only reasonable way to make progress.</div>
<div><br></div><div><br></div><div>I also don't think we need to get complete agreement among all of the tool chains that may ever implement Address Sanitizer like features in order to make forward progress. Past a certain point, other tool chains can simply grow as much of this feature as they need if/when they want to support the syntax.</div>
</div>