Details
- Reviewers
Mordante philnik - Group Reviewers
Restricted Project - Commits
- rGf418cb1a9367: [libc++] Fix `std::out_of_range` thrown from `basic_stringbuf::str() &&`
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Fixes a bug reported by @leonardchan at https://reviews.llvm.org/D155276
In the bug scenario, __view.data() == nullptr. The offset is validated by the string constructor/assign even if count == 0.
Thanks for the quick fix! LGTM modulo a comment.
After you land the patch, can you put it up for backporting to LLVM-17?
(The instructions are here https://www.llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches)
libcxx/include/sstream | ||
---|---|---|
405 | Depending on the order of evaluation __view.data() - __str_.data() may be used after __str_ has been moved. Lets determine the size before assign. This is pre-existing. Whether this is save depends on the order in which the function arguments are evaluated. Clang and GCC use a different order. |
libcxx/include/sstream | ||
---|---|---|
405 | I was also having this concern for a moment. :) But std::move is just a cast that does not modify its argument. The actual move is inside assign. |
libcxx/include/sstream | ||
---|---|---|
405 | Good point, you're right. It only does a cast and nothing else. |
libcxx/include/sstream | ||
---|---|---|
405 | While that is true, I think moving the calculation out of the function call doesn't hurt. This would be a real bug if assign took the string by value, which makes this really subtile and definitely worthy of a comment if we were to keep it this way. |
Depending on the order of evaluation __view.data() - __str_.data() may be used after __str_ has been moved. Lets determine the size before assign. This is pre-existing.
Whether this is save depends on the order in which the function arguments are evaluated. Clang and GCC use a different order.