There is a possible overflow in span.subspan as described here https://github.com/microsoft/STL/issues/159
Interestingly the other three overloads are already correct.
While we are there use element_type rather than _Tp
Differential D68952
Guard against possible overflow in span.subpan miscco on Oct 14 2019, 11:48 AM. Authored by
Details
There is a possible overflow in span.subspan as described here https://github.com/microsoft/STL/issues/159 Interestingly the other three overloads are already correct. While we are there use element_type rather than _Tp
Diff Detail Event TimelineComment Actions As a side note we could also simplify the non templated subspan method constexpr span<element_type, dynamic_extent> _LIBCPP_INLINE_VISIBILITY subspan(index_type __offset, index_type __count = dynamic_extent) const noexcept { _LIBCPP_ASSERT(__offset <= size(), "Offset out of range in span::subspan(offset, count)"); _LIBCPP_ASSERT(__count <= size() || __count == dynamic_extent, "count out of range in span::subspan(offset, count)"); if (__count == dynamic_extent) return {data() + __offset, size() - __offset}; _LIBCPP_ASSERT(__offset <= size() - __count, "Offset + count out of range in span::subspan(offset, count)"); return {data() + __offset, __count}; } To the equivalent constexpr span<element_type, dynamic_extent> _LIBCPP_INLINE_VISIBILITY subspan(index_type __offset, index_type __count = dynamic_extent) const noexcept { _LIBCPP_ASSERT(__offset <= size(), "Offset out of range in span::subspan(offset, count)"); _LIBCPP_ASSERT(__count == dynamic_extent || __offset <= size() - __count, "Offset + count out of range in span::subspan(offset, count)"); return {data() + __offset, __count == dynamic_extent ? size() - __offset : __count }; } If __count == dynamic_extent then the second assert is never tested. If __count != dynamic_extent then __count <= size() follows from conjunction of __offset <= size() and __offset <= size() - __count However, I wasn't too sure whether it should go into the same revision Comment Actions When implementing span for MS STL I locally used the libcx tests against my implementation, i found that there are some instances where libcxx is not fully conforming (due to rapidly shifting span specification). Should I prepare one big patch or go on incrementally.
What I find better about that code is that it is equivalent to the other subspan methods. I will definitely add a test against the error cases Comment Actions How many cases are we talking about? Comment Actions Fixed preexisting bug and added necessary static_assert in another case Also added (untested) Unit tests Comment Actions I have to appologize, but my linux distribution needs to be reset. I havent had time for that so I only wrote some logical tests and will expand once I find time to setup linux again
Comment Actions (I'm not sure how to withdraw my "Request Changes" without approving - I'm not an authorized approver for libc++ - so I'll "Resign as Reviewer" and see if my red X goes away.) Comment Actions Phabricator clears a request changes status when you upload a new version, so in this case you didn't need to do anything. In the general case though, I've found that the only way to clear an active request changes is to approve and then resign as reviewer. Resigning as reviewer clears your approval, but doesn't clear a request changes. |
Pre-existing bug: The return type should be span<element_type, _Count>.