Skip to content

Implement LWG-3662 string::append/assign(NTBS, pos, n) should not construct a temporary string #6235

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
YexuanXiao wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Implement LWG-3662 string::append/assign(NTBS, pos, n) should not construct a temporary string #6235

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions stl/inc/xstring
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1556,6 +1556,16 @@ public:
}
#endif // _HAS_CXX17

_CONSTEXPR20 basic_string& append(
_In_reads_(_Count) const _Elem* const _Ptr, const size_type _Off, _CRT_GUARDOVERFLOW const size_type _Count) {
Copy link

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SAL annotation _In_reads_(_Count) is inaccurate for this NTBS overload because the implementation calls _Traits::length(_Ptr) (reads until null terminator, potentially beyond _Count) and then appends only a clamped subrange. For consistency with other NTBS-taking overloads in this file (e.g. append(_In_z_ const _Elem*)), this should be annotated as _In_z_ (and similarly for assign).

This issue also appears on line 1658 of the same file.

Suggested change
_In_reads_(_Count) const _Elem* const _Ptr, const size_type _Off, _CRT_GUARDOVERFLOW const size_type _Count) {
_In_z_ const _Elem* const _Ptr, const size_type _Off, _CRT_GUARDOVERFLOW const size_type _Count) {

Copilot uses AI. Check for mistakes.
// append(string_view(_Ptr).substr(_Off, _Count))
const size_type _Length = _Convert_size<size_type>(_Traits::length(_Ptr));
if (_Off > _Length) {
_Scary_val::_Xran();
}
return _Append(_Ptr + _Off, (_STD min) (_Length - _Off, _Count));
}
Comment on lines +1559 to +1567
Copy link

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These new append(const _Elem*, size_type, size_type) and assign(const _Elem*, size_type, size_type) overloads appear to be C++23 additions (similar to other C++23-only basic_string members like contains/append_range which are guarded by _HAS_CXX23). As written, they’re unconditionally available in older language modes, which changes the overload set and can break source conformance/compatibility. Please wrap these overloads in the appropriate feature-test guard (likely #if _HAS_CXX23).

Copilot uses AI. Check for mistakes.

_CONSTEXPR20 basic_string& append(
_In_reads_(_Count) const _Elem* const _Ptr, _CRT_GUARDOVERFLOW const size_type _Count) {
// append [_Ptr, _Ptr + _Count)
Expand Down Expand Up @@ -1645,6 +1655,16 @@ public:
}
#endif // _HAS_CXX17

_CONSTEXPR20 basic_string& assign(
_In_reads_(_Count) const _Elem* const _Ptr, const size_type _Off, _CRT_GUARDOVERFLOW const size_type _Count) {
// assign(string_view(_Ptr).substr(_Off, _Count))
const size_type _Length = _Convert_size<size_type>(_Traits::length(_Ptr));
if (_Off > _Length) {
_Scary_val::_Xran();
}
return _Assign(_Ptr + _Off, (_STD min) (_Length - _Off, _Count));
}

_CONSTEXPR20 basic_string& assign(
_In_reads_(_Count) const _Elem* const _Ptr, _CRT_GUARDOVERFLOW const size_type _Count) {
// assign [_Ptr, _Ptr + _Count)
Expand Down
45 changes: 45 additions & 0 deletions tests/std/tests/VSO_0174871_string_replace/test.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,6 +103,50 @@ void test_shrink_to_fit() {
assert(example == longerStr);
}

template <typename T = char>
struct CharAllocator {
using value_type = T;

CharAllocator() = delete;
explicit CharAllocator(int) noexcept {}
template <typename U>
CharAllocator(const CharAllocator<U>&) noexcept {}

T* allocate(std::size_t n) {
return new T[n];
}
void deallocate(T* p, std::size_t) noexcept {
delete[] p;
}
};

void test_LWG3662() {
// append/assign(NTBS, pos, n) should not construct a temporary string
basic_string<char, char_traits<char>, CharAllocator<char>> s(CharAllocator<char>(0));

s.append("hello", 1, 3);
assert(s == "ell");
s.assign("world", 1, 3);
assert(s == "orl");

s.clear();

try {
s.append("hello", 10, 1);
puts("append with out-of-range position should throw");
abort();
} catch (const out_of_range&) {
// purposely do nothing on out_of_range
}
try {
s.assign("world", 10, 1);
puts("assign with out-of-range position should throw");
abort();
} catch (const out_of_range&) {
// purposely do nothing on out_of_range
}
}

int main() {
// Plain replacements with shrinking / same size / growing
test_replace(3, 3, "ab", "012ab6789");
Expand Down Expand Up @@ -142,4 +186,5 @@ int main() {

test_index_boundary_cases();
test_shrink_to_fit();
test_LWG3662();
Comment on lines 188 to +189
Copy link

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these new basic_string::append/assign(const char*, pos, n) overloads are gated to C++23 mode (as other C++23 basic_string APIs are), this call (and the test_LWG3662 definition) should be wrapped in #if _HAS_CXX23 so the test suite still compiles in earlier language modes.

Suggested change
test_shrink_to_fit();
test_LWG3662();
test_shrink_to_fit();
#if _HAS_CXX23
test_LWG3662();
#endif // _HAS_CXX23

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Contributor

@frederick-vs-ja frederick-vs-ja Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. These overloads should be added to C++14 mode (the earliest mode we support),

}