<div dir="rtl"><div dir="ltr">So, there are three options</div><div dir="ltr"><br></div><div dir="ltr">1) Go <span style="font-size:12.8000001907349px">_DEBUG_POINTER_IMPL route for VC2013 only. This will</span><span style="font-size:12.8000001907349px"> also disable the null checks in the other headers where they are beneficial and may miss real bugs.</span></div><div dir="ltr"><span style="font-size:12.8000001907349px"><br></span></div><div dir="ltr"><span style="font-size:12.8000001907349px">2) Replace std::equal with llvm::isEqual or stl::equal or ...</span></div><div dir="ltr"><span style="font-size:12.8000001907349px"><br></span></div><div dir="ltr"><span style="font-size:12.8000001907349px">3) Solve the llvm::equal ambiguity using namespace trick while making peace with the llvm::equal functor.</span></div><div dir="ltr"><span style="font-size:12.8000001907349px"><br></span></div><div dir="ltr"><span style="font-size:12.8000001907349px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-08-18 16:13 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 class="">On Mon, Aug 17, 2015 at 8:28 PM, Duncan P. N. Exon Smith<br>
<<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
><br>
>> On 2015-Aug-17, at 16:38, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
>><br>
>> On Mon, Aug 17, 2015 at 7:23 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com">yaron.keren@gmail.com</a>> wrote:<br>
>>> An  issue that was patched several times in LLVM is std::equal(nullptr,<br>
>>> nullptr, nullptr) where VC asserts on the third nullptr. Earlier in the<br>
>>> thread Marshal wrote this should return true and not assert.<br>
>><br>
>> Yes, I've fixed some myself, IIRC. Marshall's logic makes sense to me,<br>
>> and from my reading of the standard, it also seems to fit.<br>
><br>
> 25.2.11 is pretty clear:<br>
><br>
>> Returns: true if for every iterator i in the range [first1,last1) the following corresponding condi- tions hold: *i == *(first2 + (i - first1)), pred(*i, *(first2 + (i - first1))) != false. Otherwise, returns false.<br>
><br>
><br>
> Unless you're suggesting that `[nullptr, nullptr)` is an invalid<br>
> iterator range, or that `nullptr` is an invalid iterator?  But<br>
> `[nullptr, nullptr)` supports all the necessary operations for an<br>
> empty iterator range, so how could that be?  (Maybe I'm guessing<br>
> wrong and this is a straw man... in which case, how could this be<br>
> a conforming extension?)<br>
<br>
</span>I took longer to read more of the standard (specifically, the parts<br>
about library requirements in [res.on.arguments] and [iterators]), and<br>
I don't think this is a conforming extension. Then I fired up MSVC<br>
2015 and did some experiments, and realized the behavior is different<br>
in 2015, so I'm not even certain the behavior was intentional in the<br>
first place.<br>
<br>
In MSVC 2013, equal would check the range and then check the last<br>
pointer for null, and this check would trigger the assertion.<br>
In MSVC 2015, equal would check the range, and then check the last<br>
pointer for null only if the range is not empty, and so no assertion<br>
is triggered.<br>
<br>
(There is still a degenerate case bug where std::equal(nullptr,<br>
nullptr, nullptr) refuses to compile that I've reported.)<br>
<span class=""><br>
>> However,<br>
>> I'm not convinced this isn't a valid extension that prevents UB from<br>
>> calling std::memcmp() with a null pointer value.<br>
><br>
> `std::equal` isn't defined in terms of `std::memcmp()`, it's defined<br>
> as above.  How could it be valid to return anything but `true`?  The<br>
> wording is clear.<br>
><br>
> But if MSVC is calling `std::memcmp()` directly then we probably<br>
> don't have a choice but to reimplement `std::equal()` ourselves,<br>
> correctly :(.<br>
<br>
</span>I think that's true in MSVC 2013, unfortunately. However, I also think<br>
that speaks to a hackish solution limited to just MSVC 2013 being<br>
somewhat more acceptable because we will be getting rid of 2013<br>
sometime in the future (next few years).<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
>> I think LWG would<br>
>> need to weigh in on the matter, but I don't know of any issues that<br>
>> are open on this topic that we could point to for a definitive answer.<br>
>> Perhaps Marshall is aware of something, however.<br>
><br>
><br>
</div></div></blockquote></div><br></div>