[llvm] r243996 - Avoid passing nullptr to std::equal.

[Duncan P. N. Exon Smith via llvm-commits]

> On 2015-Aug-17, at 16:38, Aaron Ballman <aaron at aaronballman.com> wrote:
> 
> On Mon, Aug 17, 2015 at 7:23 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
>> 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.
> 
> Yes, I've fixed some myself, IIRC. Marshall's logic makes sense to me,
> and from my reading of the standard, it also seems to fit.

25.2.11 is pretty clear:

> 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.


Unless you're suggesting that `[nullptr, nullptr)` is an invalid
iterator range, or that `nullptr` is an invalid iterator?  But
`[nullptr, nullptr)` supports all the necessary operations for an
empty iterator range, so how could that be?  (Maybe I'm guessing
wrong and this is a straw man... in which case, how could this be
a conforming extension?)

> However,
> I'm not convinced this isn't a valid extension that prevents UB from
> calling std::memcmp() with a null pointer value.

`std::equal` isn't defined in terms of `std::memcmp()`, it's defined
as above.  How could it be valid to return anything but `true`?  The
wording is clear.

But if MSVC is calling `std::memcmp()` directly then we probably
don't have a choice but to reimplement `std::equal()` ourselves,
correctly :(.

> I think LWG would
> need to weigh in on the matter, but I don't know of any issues that
> are open on this topic that we could point to for a definitive answer.
> Perhaps Marshall is aware of something, however.