<div dir="rtl"><div dir="ltr">An  issue that was patched several times in LLVM is std::equal(nullptr, nullptr, nullptr) where VC asserts on the third nullptr. Earlier in the thread Marshal wrote this should return true and not assert.</div><div dir="ltr"><br></div><div dir="ltr">It is also possible to localize _DEBUG_POINTER_IMPL effect to algorithm only by having llvm-algorithm.h:</div><div dir="ltr"><br></div><div dir="ltr">#define _DEBUG_POINTER_IMPL</div><div dir="ltr">#include <algorithm></div><div dir="ltr"><br></div><div dir="ltr">and have every llvm source include llvm-algorithm.h instead of algorithm.</div><div dir="ltr"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-08-18 2:19 GMT+03:00 Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Aug 17, 2015 at 6:49 PM, Duncan P. N. Exon Smith<br>
<<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:<br>
><br>
>> On 2015-Aug-17, at 15:27, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>><br>
>> On Mon, Aug 17, 2015 at 6:18 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:<br>
>>> +aaron, reid<br>
>>><br>
>>> Here is a patch disabling the iterator null pointer checking in Visual C++<br>
>>> debug mode. This makes std::equal behave as expected instead of asserting on<br>
>>> std::equal(nullpt,r nullptr, nullptr), saving an extra check just for Visual<br>
>>> C++ debug mode here and there.<br>
>>><br>
>>> It should not cause any practical problem debugging as if a null iterator is<br>
>>> actually dereferenced (as opposed to compared) the debugger will stop on<br>
>>> location.<br>
>>><br>
>>> What do you think?<br>
>><br>
>> Mildly terrified. :-) This also disables really useful debugging tools<br>
>> in other parts of the STL that have definitely found bugs for us in<br>
>> the past. A lot of <algorithm>, <istream>, <ostream>, <locale>,<br>
>> <memory>, <string>, and <utility> make use of _DEBUG_POINTER, which<br>
>> this patch would disable.<br>
>><br>
>> I would *strongly* prefer to not disable that debugging functionality,<br>
>> especially since this runtime-level debugging has found bugs our own<br>
>> tests have not.<br>
>><br>
>> ~Aaron<br>
><br>
> This _DEBUG_POINTER macro seems to violate the standard in ways that<br>
> require weird workarounds for LLVM's uses of the STL.<br>
<br>
</span>In what way is it violating the standard? (I apologize if this has<br>
been answered before, but I didn't see anyone citing the standard,<br>
just some reasonable guesses.) If you believe there is a bug with<br>
MSVC, has it been reported to Microsoft, and have they weighed in on<br>
the topic?<br>
<span><font color="#888888"><br>
~Aaron<br>
</font></span><div><div><br>
> It seems better to me to make MSVC's STL standards-compliant (when<br>
> building LLVM) than to duplicate all the STL algorithms inside<br>
> `namespace llvm`, which IMO is the best alternative.<br>
><br>
> It would be awesome if there were fewer "we don't follow the standard"<br>
> gotchas that most of us only find, post-commit, in MSVC buildbots.<br>
><br>
>>> 2015-08-17 23:45 GMT+03:00 Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>>:<br>
>>>><br>
>>>><br>
>>>>> On 2015-Aug-17, at 13:43, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> I'm trying another approach. The non-null validation goes through a<br>
>>>>> macro defined to a function which possibly may be predefined to nothing.<br>
>>>>> This will disable all null checking on iterators in debug mode which is<br>
>>>>> relevant to additional functions beyond std::equal. In practice it should<br>
>>>>> not be a problem since if a null iterator is actually dereferenced (not only<br>
>>>>> compared) then the debugger stops with invalid access anyhow.<br>
>>>><br>
>>>> Well, this would be ideal :).<br>
>>><br>
>>><br>
><br>
</div></div></blockquote></div><br></div></div>