{
  "$type": "site.standard.document",
  "path": "/t/ffi-proof-slice-from-raw-parts/23971#post_7",
  "publishedAt": "2026-02-05T01:35:21.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "CVE-2018-1000810: std: Buffer overflow vulnerability in str::repeat() › RustSec Advisory Database"
  ],
  "textContent": "kornel:\n\n> because I also have cases where I really don't want that check, like iterators that use a raw pointer (due to aliasing or to hold start-end instead of start-len) and create a slice for every element\n\nIf you want to guarantee that you don't get the check, you can spell it as one of\n\n\n    NonNull::slice_from_raw_parts(NonNull::new_unchecked(ptr), len).as_ref()\n\n\nor\n\n\n    NonNull::slice_from_raw_parts(NonNull::new_unchecked(ptr), len).as_mut()\n\n\ndepending whether you want `&[_]` or `&mut [_]` respectively, all of which is available in stable.\n\nThough as the8472 noted, the change to `slice::from_raw_parts` is only approved modulo the check mostly optimizing out anyway so you probably _don't_ need to do that.\n\n* * *\n\nI'm certainly not opposed to an `ffi::something` function for this stuff, but I just overall wonder how much the checking can realistically do. It can't catch overflow like CVE-2018-1000810: std: Buffer overflow vulnerability in str::repeat() › RustSec Advisory Database, for example, and adversarial buffer sizes need not get anywhere near `isize::MAX`.",
  "title": "FFI-proof slice::from_raw_parts"
}