diff options
| author | Eric Fiselier <eric@efcs.ca> | 2019-03-09 00:38:19 +0000 |
|---|---|---|
| committer | Eric Fiselier <eric@efcs.ca> | 2019-03-09 00:38:19 +0000 |
| commit | 7ffcd984c4de54dea96049b9cb6a74c9e9b84c1e (patch) | |
| tree | f005738dd727154282520d1443c442c3a62f7ca1 /libcxx/www | |
| parent | c5bfa3dafb3e7ccc871734a96b7a9188868d925a (diff) | |
| download | bcm5719-llvm-7ffcd984c4de54dea96049b9cb6a74c9e9b84c1e.tar.gz bcm5719-llvm-7ffcd984c4de54dea96049b9cb6a74c9e9b84c1e.zip | |
LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"
Patch by Arthur O'Dwyer.
Reviewed as https://reviews.llvm.org/D47344
new_delete_resource().allocate(n, a) has basically two permissible results:
* Return an appropriately sized and aligned block.
* Throw bad_alloc.
Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was
to return an appropriately sized but inappropriately under-aligned block. This is now fixed.
(This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't
trust the default resource to return appropriately aligned blocks, pretty much everything breaks.
For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't
care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.)
llvm-svn: 355763
Diffstat (limited to 'libcxx/www')
| -rw-r--r-- | libcxx/www/cxx2a_status.html | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libcxx/www/cxx2a_status.html b/libcxx/www/cxx2a_status.html index 67f1e2f81e7..4489399ebba 100644 --- a/libcxx/www/cxx2a_status.html +++ b/libcxx/www/cxx2a_status.html @@ -219,7 +219,7 @@ <tr><td><a href="https://wg21.link/LWG2164">2164</a></td><td>What are the semantics of <tt>vector.emplace(vector.begin(), vector.back())</tt>?</td><td>Jacksonville</td><td></td></tr> <tr><td><a href="https://wg21.link/LWG2243">2243</a></td><td><tt>istream::putback</tt> problem</td><td>Jacksonville</td><td>Complete</td></tr> <tr><td><a href="https://wg21.link/LWG2816">2816</a></td><td><tt>resize_file</tt> has impossible postcondition</td><td>Jacksonville</td><td><i>Nothing to do</i></td></tr> - <tr><td><a href="https://wg21.link/LWG2843">2843</a></td><td>Unclear behavior of <tt>std::pmr::memory_resource::do_allocate()</tt></td><td>Jacksonville</td><td></td></tr> + <tr><td><a href="https://wg21.link/LWG2843">2843</a></td><td>Unclear behavior of <tt>std::pmr::memory_resource::do_allocate()</tt></td><td>Jacksonville</td><td>Complete</td></tr> <tr><td><a href="https://wg21.link/LWG2849">2849</a></td><td>Why does <tt>!is_regular_file(from)</tt> cause <tt>copy_file</tt> to report a "file already exists" error?</td><td>Jacksonville</td><td><i>Nothing to do</i></td></tr> <tr><td><a href="https://wg21.link/LWG2851">2851</a></td><td><tt>std::filesystem</tt> enum classes are now underspecified</td><td>Jacksonville</td><td><i>Nothing to do</i></td></tr> <tr><td><a href="https://wg21.link/LWG2946">2946</a></td><td>LWG 2758's resolution missed further corrections</td><td>Jacksonville</td><td>Complete</td></tr> |
