-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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.
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
str::buf_as_slice includes (and reads) uninitialized memory in the slice #3843
Comments
curiously it seems nobody uses this at the moment; I agree it shouldn't read possibly-invalid memory, but can we either say len should be one-longer than the intended length, and/or len+1 must be valid memory (as a precondition)? Or is this a general relative of the 'maybe str should not include a trailing byte' bug? |
non-critical for 0.6, de-milestoning |
1 similar comment
non-critical for 0.6, de-milestoning |
@graydon We can state some precondition in the docs, yes. It will be error prone, but I suppose that's the nature of Not really related - with region pointers I think these types of functions that temporarily cast an unsafe pointer to another type in a closure aren't a best practice. We ought to just fabricate a region (would be nice to have a dedicated |
@brson An "unsafe" region wouldn't be necessary for that; you'd want to write But I suggest this function shouldn't be removed entirely (perhaps replaced with a safe |
I also note that the function is "currently safe" because its only caller ensures that there's a null in the appropriate spot. |
Add common lint tools doc This PR starts adding some documentation about linting tools. `Retrieving all methods of a type` is not covered at this time. fixes partially: rust-lang#3843 changelog: none
…hansch,flip1995 Add doc for checking if type defines specific method This PR adds documentation on how: - check if a type defines a specific method - check an expr is calling a specific method closes: rust-lang#3843 changelog: none
… r=RalfJung Make TB tree traversal bottom-up In preparation for rust-lang#3837, the tree traversal needs to be made bottom-up, because the current top-down tree traversal, coupled with that PR's changes to the garbage collector, can introduce non-deterministic error messages if the GC removes a parent tag of the accessed tag that would have triggered the error first. This is a breaking change for the diagnostics emitted by TB. The implemented semantics stay the same.
…e-gc, r=RalfJung Make Tree Borrows Provenance GC compact the tree Follow-up on rust-lang#3833 and rust-lang#3835. In these PRs, the TB GC was fixed to no longer cause a stack overflow. One test that motivated it was the test `fill::horizontal_line` in [`tiny-skia`](https://github.com/RazrFalcon/tiny-skia). But not causing stack overflows was not a large improvents, since it did not fix the fundamental issue: The tree was too large. The test now ran, but it required gigabytes of memory and hours of time (only for it to be OOM-killed 🤬), whereas it finishes within 24 seconds in Stacked Borrows. With this merged, it finishes in about 40 seconds under TB. The problem in that test was that it used [`slice::chunked`](https://doc.rust-lang.org/std/primitive.slice.html#method.chunks) to iterate a slice in chunks. That iterator is written to reborrow at each call to `next`, which creates a linear tree with a bunch of intermediary nodes, which also fragments the `RangeMap` for that allocation. The solution is to now compact the tree, so that these interior nodes are removed. Care is taken to not remove nodes that are protected, or that otherwise restrict their children. I am currently only 99% sure that this is sound, and I do also think that this could compact even more. So `@Vanille-N` please also have a look at whether I got the compacting logic right. For a more visual comparison, [here is a gist](https://gist.github.com/JoJoDeveloping/ae4a7f7c29335a4c233ef42d2f267b01) of what the tree looks like at one point during that test, with and without compacting. This new GC requires a different iteration order during accesses (since the current one can make the error messages non-deterministic), so it is rebased on top of rust-lang#3843 and requires that PR to be merged first.
As long as string slices expect to have an extra byte at the end this function cannot be expressed without copying. Here's how it's written:
That extra byte in
len + 1
is just random memory, whichis_utf8
immediately reads.The text was updated successfully, but these errors were encountered: