Commit b4fcf48
authored
Rollup merge of rust-lang#63216 - oconnor663:take_read_to_end, r=sfackler
avoid unnecessary reservations in std::io::Take::read_to_end
Prevously the `read_to_end` implementation for `std::io::Take` used its
own `limit` as a cap on the `reservation_size`. However, that could
still result in an over-allocation like this:
1. Call `reader.take(5).read_to_end(&mut vec)`.
2. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
3. `read` writes 5 bytes.
4. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
5. `read` writes 0 bytes.
6. The read loop ends with `vec` having length 5 and capacity 10.
The reservation of 5 bytes was correct for the read at step 2 but
unnecessary for the read at step 4. By that second read, `Take::limit`
is 0, but the `read_to_end_with_reservation` loop is still using the
same `reservation_size` it started with.
Solve this by having `read_to_end_with_reservation` take a closure,
which lets it get a fresh `reservation_size` for each read. This is an
implementation detail which doesn't affect any public API.1 file changed
+58
-8
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
353 | 353 | | |
354 | 354 | | |
355 | 355 | | |
356 | | - | |
| 356 | + | |
357 | 357 | | |
358 | 358 | | |
359 | | - | |
360 | | - | |
361 | | - | |
| 359 | + | |
| 360 | + | |
| 361 | + | |
| 362 | + | |
| 363 | + | |
| 364 | + | |
| 365 | + | |
| 366 | + | |
362 | 367 | | |
363 | 368 | | |
364 | 369 | | |
365 | 370 | | |
366 | 371 | | |
367 | 372 | | |
368 | 373 | | |
369 | | - | |
| 374 | + | |
370 | 375 | | |
371 | 376 | | |
372 | 377 | | |
| |||
2253 | 2258 | | |
2254 | 2259 | | |
2255 | 2260 | | |
2256 | | - | |
2257 | | - | |
2258 | | - | |
| 2261 | + | |
| 2262 | + | |
| 2263 | + | |
| 2264 | + | |
2259 | 2265 | | |
2260 | 2266 | | |
2261 | 2267 | | |
| |||
2378 | 2384 | | |
2379 | 2385 | | |
2380 | 2386 | | |
| 2387 | + | |
2381 | 2388 | | |
2382 | 2389 | | |
2383 | 2390 | | |
| |||
2651 | 2658 | | |
2652 | 2659 | | |
2653 | 2660 | | |
| 2661 | + | |
| 2662 | + | |
| 2663 | + | |
| 2664 | + | |
| 2665 | + | |
| 2666 | + | |
| 2667 | + | |
| 2668 | + | |
| 2669 | + | |
| 2670 | + | |
| 2671 | + | |
| 2672 | + | |
| 2673 | + | |
| 2674 | + | |
| 2675 | + | |
| 2676 | + | |
| 2677 | + | |
| 2678 | + | |
| 2679 | + | |
| 2680 | + | |
| 2681 | + | |
| 2682 | + | |
| 2683 | + | |
| 2684 | + | |
| 2685 | + | |
| 2686 | + | |
| 2687 | + | |
| 2688 | + | |
| 2689 | + | |
| 2690 | + | |
| 2691 | + | |
| 2692 | + | |
| 2693 | + | |
| 2694 | + | |
| 2695 | + | |
| 2696 | + | |
| 2697 | + | |
| 2698 | + | |
| 2699 | + | |
| 2700 | + | |
| 2701 | + | |
| 2702 | + | |
| 2703 | + | |
2654 | 2704 | | |
2655 | 2705 | | |
2656 | 2706 | | |
| |||
0 commit comments