<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/libcxx/test/std/strings/basic.string/string.modifiers, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[libc++][C++03] cherry-pick #125423 (#156824)</title>
<updated>2025-09-05T12:45:58+00:00</updated>
<author>
<name>Nikolas Klauser</name>
<email>nikolasklauser@berlin.de</email>
</author>
<published>2025-09-05T12:45:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2e6685c5c680cfeb7f7c0200a1bdc7c8f0b8a4d0'/>
<id>2e6685c5c680cfeb7f7c0200a1bdc7c8f0b8a4d0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][test] Test `nasty_string` in C++20 (#135338)</title>
<updated>2025-04-13T03:23:13+00:00</updated>
<author>
<name>A. Jiang</name>
<email>de34@live.cn</email>
</author>
<published>2025-04-13T03:23:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3e7be494f84e51d5f4245d6f39e380a500f226a6'/>
<id>3e7be494f84e51d5f4245d6f39e380a500f226a6</id>
<content type='text'>
It seems that we can only rely on C++20 features and make `nasty_string`
also tested for MSVC STL.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It seems that we can only rely on C++20 features and make `nasty_string`
also tested for MSVC STL.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++] Fix basic_string not allowing max_size() elements to be stored (#125423)</title>
<updated>2025-02-23T18:02:14+00:00</updated>
<author>
<name>Nikolas Klauser</name>
<email>nikolasklauser@berlin.de</email>
</author>
<published>2025-02-23T18:02:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=15860446a8c3db5c39f92bb371236778e8b00fb0'/>
<id>15860446a8c3db5c39f92bb371236778e8b00fb0</id>
<content type='text'>
Without this patch `basic_string` cannot be properly resized to be
`max_size()` elements in size, even if an allocation is successful.
`__grow_by` allocates one less element than required, resulting in an
out-of-bounds access. At the same time, `max_size()` has an off-by-one
error, since there has to be space to store the null terminator, which
is currently ignored.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Without this patch `basic_string` cannot be properly resized to be
`max_size()` elements in size, even if an allocation is successful.
`__grow_by` allocates one less element than required, resulting in an
out-of-bounds access. At the same time, `max_size()` has an off-by-one
error, since there has to be space to store the null terminator, which
is currently ignored.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++] Fix input-only range handling for `basic_string` (#116890)</title>
<updated>2025-01-21T21:29:32+00:00</updated>
<author>
<name>A. Jiang</name>
<email>de34@live.cn</email>
</author>
<published>2025-01-21T21:29:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=80097a1fa5c776790c1f0b313cfac923d86a82f9'/>
<id>80097a1fa5c776790c1f0b313cfac923d86a82f9</id>
<content type='text'>
By calling `std::move` for related functions when the iterator is
possibly input-only. Also slightly changes the conditions of branch for
contiguous iterators to avoid error.

Fixes #116502</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
By calling `std::move` for related functions when the iterator is
possibly input-only. Also slightly changes the conditions of branch for
contiguous iterators to avoid error.

Fixes #116502</pre>
</div>
</content>
</entry>
<entry>
<title> [libcxx] Add testing configuration for GPU targets (#104515)</title>
<updated>2024-11-04T18:58:23+00:00</updated>
<author>
<name>Joseph Huber</name>
<email>huberjn@outlook.com</email>
</author>
<published>2024-11-04T18:58:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=95a2eb70cf850597a5e871380807911e55f341a7'/>
<id>95a2eb70cf850597a5e871380807911e55f341a7</id>
<content type='text'>
Summary:
The GPU runs these tests using the files built from the `libc` project.
These will be placed in `include/&lt;triple&gt;` and `lib/&lt;triple&gt;`. We use
the `amdhsa-loader` and `nvptx-loader` tools, which are also provided by
`libc`. These launch a kernel called `_start` which calls `main` so we
can pretend like GPU programs are normal terminal applications.

We force serial exeuction here, because `llvm-lit` runs way too many
processes in parallel, which has a bad habit of making the GPU drivers
hang or run out of resources. This allows the compilation to be run in
parallel while the jobs themselves are serialized via a file lock.

In the future this can likely be refined to accept user specified
architectures, or better handle including the root directory by exposing
that instead of just `include/&lt;triple&gt;/c++/v1/`.

This currently fails ~1% of the tests on AMDGPU and ~3% of the tests on
NVPTX. This will hopefully be reduced further, and later patches can
XFAIL a lot of them once it's down to a reasonable number.

Future support will likely want to allow passing in a custom
architecture instead of simply relying on `-mcpu=native`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
The GPU runs these tests using the files built from the `libc` project.
These will be placed in `include/&lt;triple&gt;` and `lib/&lt;triple&gt;`. We use
the `amdhsa-loader` and `nvptx-loader` tools, which are also provided by
`libc`. These launch a kernel called `_start` which calls `main` so we
can pretend like GPU programs are normal terminal applications.

We force serial exeuction here, because `llvm-lit` runs way too many
processes in parallel, which has a bad habit of making the GPU drivers
hang or run out of resources. This allows the compilation to be run in
parallel while the jobs themselves are serialized via a file lock.

In the future this can likely be refined to accept user specified
architectures, or better handle including the root directory by exposing
that instead of just `include/&lt;triple&gt;/c++/v1/`.

This currently fails ~1% of the tests on AMDGPU and ~3% of the tests on
NVPTX. This will hopefully be reduced further, and later patches can
XFAIL a lot of them once it's down to a reasonable number.

Future support will likely want to allow passing in a custom
architecture instead of simply relying on `-mcpu=native`.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++] Implements LWG3130. (#101889)</title>
<updated>2024-08-06T17:47:56+00:00</updated>
<author>
<name>Mark de Wever</name>
<email>koraq@xs4all.nl</email>
</author>
<published>2024-08-06T17:47:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4dee6411e0d993fd17099bd7564276474412383e'/>
<id>4dee6411e0d993fd17099bd7564276474412383e</id>
<content type='text'>
This adds addressof at the required places in [input.output]. Some of
the new tests failed since string used operator&amp; internally. These have
been fixed too.

Note the new fstream tests perform output to a basic_string instead of a
double. Using a double requires num_get specialization

num_get&lt;CharT, istreambuf_iterator&lt;CharT,
char_traits_operator_hijacker&lt;CharT&gt;&gt;

This facet is not present in the locale database so the conversion would
fail due to a missing locale facet. Using basic_string avoids using the
locale.

As a drive-by fixes several bugs in the ofstream.cons tests. These
tested ifstream instead of ofstream with an open mode.

Implements:
- LWG3130 [input.output] needs many addressof

Closes #100246.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds addressof at the required places in [input.output]. Some of
the new tests failed since string used operator&amp; internally. These have
been fixed too.

Note the new fstream tests perform output to a basic_string instead of a
double. Using a double requires num_get specialization

num_get&lt;CharT, istreambuf_iterator&lt;CharT,
char_traits_operator_hijacker&lt;CharT&gt;&gt;

This facet is not present in the locale database so the conversion would
fail due to a missing locale facet. Using basic_string avoids using the
locale.

As a drive-by fixes several bugs in the ofstream.cons tests. These
tested ifstream instead of ofstream with an open mode.

Implements:
- LWG3130 [input.output] needs many addressof

Closes #100246.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][NFC] Avoid opening namespace std in the tests (#94160)</title>
<updated>2024-08-01T08:57:21+00:00</updated>
<author>
<name>Nikolas Klauser</name>
<email>nikolasklauser@berlin.de</email>
</author>
<published>2024-08-01T08:57:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5dfdac74cadd9483a66eb17e51dc632b554cccb1'/>
<id>5dfdac74cadd9483a66eb17e51dc632b554cccb1</id>
<content type='text'>
This also adds a few FIXMEs where we use UB in the tests.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This also adds a few FIXMEs where we use UB in the tests.</pre>
</div>
</content>
</entry>
<entry>
<title>[ASan][libc++] Correct (explicit) annotation size (#79292)</title>
<updated>2024-01-25T19:41:38+00:00</updated>
<author>
<name>Tacet</name>
<email>advenam.tacet@trailofbits.com</email>
</author>
<published>2024-01-25T19:41:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a315fb1c577a40a40968daa9d346435458d7e06e'/>
<id>a315fb1c577a40a40968daa9d346435458d7e06e</id>
<content type='text'>
A quick examination suggests that the current code in the codebase does
not lead to incorrect annotations. However, the intention is for the
object after the function to be annotated in a way that only its
contents are unpoisoned and the rest is poisoned. This commit makes it
explicit and avoids potential issues in future.

In addition, I have implemented a few tests for a function that helped
me identify the specific argument value.

Notice: there is no known scenario where old code results in incorrect
annotation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A quick examination suggests that the current code in the codebase does
not lead to incorrect annotations. However, the intention is for the
object after the function to be annotated in a way that only its
contents are unpoisoned and the rest is poisoned. This commit makes it
explicit and avoids potential issues in future.

In addition, I have implemented a few tests for a function that helped
me identify the specific argument value.

Notice: there is no known scenario where old code results in incorrect
annotation.</pre>
</div>
</content>
</entry>
<entry>
<title>[ASan][libc++] std::basic_string annotations (#72677)</title>
<updated>2023-12-13T05:05:34+00:00</updated>
<author>
<name>Tacet</name>
<email>advenam.tacet@trailofbits.com</email>
</author>
<published>2023-12-13T05:05:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9ed20568e7de53dce85f1631d7d8c1415e7930ae'/>
<id>9ed20568e7de53dce85f1631d7d8c1415e7930ae</id>
<content type='text'>
This commit introduces basic annotations for `std::basic_string`,
mirroring the approach used in `std::vector` and `std::deque`.
Initially, only long strings with the default allocator will be
annotated. Short strings (_SSO - short string optimization_) and strings
with non-default allocators will be annotated in the near future, with
separate commits dedicated to enabling them. The process will be similar
to the workflow employed for enabling annotations in `std::deque`.

**Please note**: these annotations function effectively only when libc++
and libc++abi dylibs are instrumented (with ASan). This aligns with the
prevailing behavior of Memory Sanitizer.

To avoid breaking everything, this commit also appends
`_LIBCPP_INSTRUMENTED_WITH_ASAN` to `__config_site` whenever libc++ is
compiled with ASan. If this macro is not defined, string annotations are
not enabled. However, linking a binary that does **not** annotate
strings with a dynamic library that annotates strings, is not permitted.

Originally proposed here: https://reviews.llvm.org/D132769

Related patches on Phabricator:
- Turning on annotations for short strings:
https://reviews.llvm.org/D147680
- Turning on annotations for all allocators:
https://reviews.llvm.org/D146214

This PR is a part of a series of patches extending AddressSanitizer C++
container overflow detection capabilities by adding annotations, similar
to those existing in `std::vector` and `std::deque` collections. These
enhancements empower ASan to effectively detect instances where the
instrumented program attempts to access memory within a collection's
internal allocation that remains unused. This includes cases where
access occurs before or after the stored elements in `std::deque`, or
between the `std::basic_string`'s size (including the null terminator)
and capacity bounds.

The introduction of these annotations was spurred by a real-world
software bug discovered by Trail of Bits, involving an out-of-bounds
memory access during the comparison of two strings using the
`std::equals` function. This function was taking iterators
(`iter1_begin`, `iter1_end`, `iter2_begin`) to perform the comparison,
using a custom comparison function. When the `iter1` object exceeded the
length of `iter2`, an out-of-bounds read could occur on the `iter2`
object. Container sanitization, upon enabling these annotations, would
effectively identify and flag this potential vulnerability.

This Pull Request introduces basic annotations for `std::basic_string`.
Long strings exhibit structural similarities to `std::vector` and will
be annotated accordingly. Short strings are already implemented, but
will be turned on separately in a forthcoming commit. Look at [a
comment](https://github.com/llvm/llvm-project/pull/72677#issuecomment-1850554465)
below to read about SSO issues at current moment.

Due to the functionality introduced in
[D132522](https://github.com/llvm/llvm-project/commit/dd1b7b797a116eed588fd752fbe61d34deeb24e4),
the `__sanitizer_annotate_contiguous_container` function now offers
compatibility with all allocators. However, enabling this support will
be done in a subsequent commit. For the time being, only strings with
the default allocator will be annotated.

If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit introduces basic annotations for `std::basic_string`,
mirroring the approach used in `std::vector` and `std::deque`.
Initially, only long strings with the default allocator will be
annotated. Short strings (_SSO - short string optimization_) and strings
with non-default allocators will be annotated in the near future, with
separate commits dedicated to enabling them. The process will be similar
to the workflow employed for enabling annotations in `std::deque`.

**Please note**: these annotations function effectively only when libc++
and libc++abi dylibs are instrumented (with ASan). This aligns with the
prevailing behavior of Memory Sanitizer.

To avoid breaking everything, this commit also appends
`_LIBCPP_INSTRUMENTED_WITH_ASAN` to `__config_site` whenever libc++ is
compiled with ASan. If this macro is not defined, string annotations are
not enabled. However, linking a binary that does **not** annotate
strings with a dynamic library that annotates strings, is not permitted.

Originally proposed here: https://reviews.llvm.org/D132769

Related patches on Phabricator:
- Turning on annotations for short strings:
https://reviews.llvm.org/D147680
- Turning on annotations for all allocators:
https://reviews.llvm.org/D146214

This PR is a part of a series of patches extending AddressSanitizer C++
container overflow detection capabilities by adding annotations, similar
to those existing in `std::vector` and `std::deque` collections. These
enhancements empower ASan to effectively detect instances where the
instrumented program attempts to access memory within a collection's
internal allocation that remains unused. This includes cases where
access occurs before or after the stored elements in `std::deque`, or
between the `std::basic_string`'s size (including the null terminator)
and capacity bounds.

The introduction of these annotations was spurred by a real-world
software bug discovered by Trail of Bits, involving an out-of-bounds
memory access during the comparison of two strings using the
`std::equals` function. This function was taking iterators
(`iter1_begin`, `iter1_end`, `iter2_begin`) to perform the comparison,
using a custom comparison function. When the `iter1` object exceeded the
length of `iter2`, an out-of-bounds read could occur on the `iter2`
object. Container sanitization, upon enabling these annotations, would
effectively identify and flag this potential vulnerability.

This Pull Request introduces basic annotations for `std::basic_string`.
Long strings exhibit structural similarities to `std::vector` and will
be annotated accordingly. Short strings are already implemented, but
will be turned on separately in a forthcoming commit. Look at [a
comment](https://github.com/llvm/llvm-project/pull/72677#issuecomment-1850554465)
below to read about SSO issues at current moment.

Due to the functionality introduced in
[D132522](https://github.com/llvm/llvm-project/commit/dd1b7b797a116eed588fd752fbe61d34deeb24e4),
the `__sanitizer_annotate_contiguous_container` function now offers
compatibility with all allocators. However, enabling this support will
be done in a subsequent commit. For the time being, only strings with
the default allocator will be annotated.

If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com</pre>
</div>
</content>
</entry>
<entry>
<title>Add `std::basic_string` test cases (#74830)</title>
<updated>2023-12-12T20:41:59+00:00</updated>
<author>
<name>Tacet</name>
<email>advenam.tacet@trailofbits.com</email>
</author>
<published>2023-12-12T20:41:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c77cdbac9b121611121adf5806a99aff4812a40c'/>
<id>c77cdbac9b121611121adf5806a99aff4812a40c</id>
<content type='text'>
Extend `std::basic_string` tests to cover more buffer situations and
length in general, particularly non-SSO cases after SSO test cases
(changing buffers). This commit is a side effect of working on tests for
ASan annotations.

Related PR: https://github.com/llvm/llvm-project/pull/72677</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Extend `std::basic_string` tests to cover more buffer situations and
length in general, particularly non-SSO cases after SSO test cases
(changing buffers). This commit is a side effect of working on tests for
ASan annotations.

Related PR: https://github.com/llvm/llvm-project/pull/72677</pre>
</div>
</content>
</entry>
</feed>
