<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/libcxx/test/std/strings/basic.string/string.modifiers/string_append/append_range.pass.cpp, 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>[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>[libc++][test] Fix unused and nodiscard warnings (#73437)</title>
<updated>2023-11-26T17:00:18+00:00</updated>
<author>
<name>Stephan T. Lavavej</name>
<email>stl@nuwen.net</email>
</author>
<published>2023-11-26T17:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=346a29908e0a0401073169ea94c17be72a9c83db'/>
<id>346a29908e0a0401073169ea94c17be72a9c83db</id>
<content type='text'>
Found while running libc++'s test suite with MSVC's STL.

This is structured into a series of commits for easier reviewing; I
could also split this into smaller PRs if desired.

* Add void-casts for `invoke_r` calls to fix MSVC STL `[[nodiscard]]`
warnings.
+ Our rationale is that if someone is calling `invoke_r&lt;NonVoidType&gt;`,
it sure looks like they care about the return value.
* Add `[[maybe_unused]]` to silence `-Wunused-parameter` warnings.
+ This happens because the parameters are used within `LIBCPP_ASSERT`,
which vanishes for MSVC's STL. This also motivates the following
changes.
* Add `[[maybe_unused]]` to fix `-Wunused-variable` warnings.
* Always void-cast `debug_comparisons` to fix `-Wunused-variable`
warnings.
+ As this was already unused with a void-cast in one
`_LIBCPP_HARDENING_MODE` branch, I'm simply lifting it next to the
variable definition.
* Add `[[maybe_unused]]` to fix `-Wunused-local-typedef` warnings.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Found while running libc++'s test suite with MSVC's STL.

This is structured into a series of commits for easier reviewing; I
could also split this into smaller PRs if desired.

* Add void-casts for `invoke_r` calls to fix MSVC STL `[[nodiscard]]`
warnings.
+ Our rationale is that if someone is calling `invoke_r&lt;NonVoidType&gt;`,
it sure looks like they care about the return value.
* Add `[[maybe_unused]]` to silence `-Wunused-parameter` warnings.
+ This happens because the parameters are used within `LIBCPP_ASSERT`,
which vanishes for MSVC's STL. This also motivates the following
changes.
* Add `[[maybe_unused]]` to fix `-Wunused-variable` warnings.
* Always void-cast `debug_comparisons` to fix `-Wunused-variable`
warnings.
+ As this was already unused with a void-cast in one
`_LIBCPP_HARDENING_MODE` branch, I'm simply lifting it next to the
variable definition.
* Add `[[maybe_unused]]` to fix `-Wunused-local-typedef` warnings.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++] Apply clang formatting to all string unit tests</title>
<updated>2023-09-01T17:35:18+00:00</updated>
<author>
<name>Brendan Emery</name>
<email>brendan.emery@esrlabs.com</email>
</author>
<published>2023-09-01T17:27:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a40bada91aeda276a772acfbcae6e8de26755a11'/>
<id>a40bada91aeda276a772acfbcae6e8de26755a11</id>
<content type='text'>
This applies clang-format to the std::string unit tests in preparation
for landing https://reviews.llvm.org/D140550.

Differential Revision: https://reviews.llvm.org/D140612
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This applies clang-format to the std::string unit tests in preparation
for landing https://reviews.llvm.org/D140550.

Differential Revision: https://reviews.llvm.org/D140612
</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][ranges] Implement the changes to `basic_string` from P1206 (`ranges::to`):</title>
<updated>2023-07-05T21:50:59+00:00</updated>
<author>
<name>varconst</name>
<email>varconsteq@gmail.com</email>
</author>
<published>2023-07-01T00:04:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=baf6f91851edcdd72e3a6214299f295ec58337f6'/>
<id>baf6f91851edcdd72e3a6214299f295ec58337f6</id>
<content type='text'>
- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.

(Note: this patch is split from https://reviews.llvm.org/D142335)

Differential Revision: https://reviews.llvm.org/D149832
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.

(Note: this patch is split from https://reviews.llvm.org/D142335)

Differential Revision: https://reviews.llvm.org/D149832
</pre>
</div>
</content>
</entry>
</feed>
