That&#x27;s still not a particularly useful metric because the vast majority of the &quot;lib&quot; directories being counted there are for the compiler itself (e.g. libsyntax, librustc_blahblah), yet more test cases (e.g. libcoretest), deprecated (e.g. librand), or miscellaneous (e.g. librustdoc, liballoc_jemalloc).<p>For the context of the OP, all we care about are unsafe blocks that have effects on the semantics of generated code. This means that all we care about are the unsafe blocks in the standard library.<p>The standard library itself is composed of a few libraries, which can be determined by looking at the `extern crate` statements in this file: <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;blob&#x2F;master&#x2F;src&#x2F;libstd&#x2F;lib.rs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;blob&#x2F;master&#x2F;src&#x2F;libstd&#x2F;lib...</a> . Ignore libtest and liblog because they&#x27;re conditionally used only in &quot;test&quot; mode. Ignore librand because it&#x27;s deprecated. That leaves libcore, libcollections, liballoc, librustc_unicode, and liblibc (and then we must also consider libstd itself). Of these, we&#x27;re going to ignore liblibc because it&#x27;s just a wrapper over libc, and any `unsafe` in there is going to be uninteresting. We&#x27;re also going to ignore the specific directory &quot;libstd&#x2F;sys&quot; because these are wrappers over system-specific low-level APIs and are going to be overwhelmingly uninteresting as well.<p>You also didn&#x27;t restrict your search to .rs files, so we&#x27;ll do that too. Here&#x27;s the final tally for each lib directory (using the latest Rust checkout), according to the following command:<p><pre><code>  git grep -v &quot;^\s*&#x2F;&#x2F;&quot; -- &quot;*.rs&quot; | grep &quot;unsafe {&quot; | wc -l
</code></pre>
libstd (sans sys): 344<p>libcore: 151<p>libcollections: 155<p>liballoc: 49<p>librustc_unicode: 2<p>Total: 701<p>This is still going to be an overestimate because, looking at the lines that are left, many of them are calling compiler intrinsics directly which is as uninteresting as calling C code. You could reduce even that number by writing a wrapper function that encapsulates the intrinsic into a safe function, but that exposes yet another problem with the &quot;counting the number of occurrences of `unsafe`&quot; metric&quot;: the precise number of `unsafe` blocks in a chunk of code is subjective.<p>You could have one big block for many consecutive unsafe operations, or you could have fine-grained unsafe blocks for each individual unsafe operation. It&#x27;s up to the author (and there are arguments in favor of each). Furthermore, the precise number of actually-unsafe operations <i>within</i> a module that uses `unsafe` is up to the discretion of the module author (I recommend reading <a href="http:&#x2F;&#x2F;doc.rust-lang.org&#x2F;nightly&#x2F;nomicon&#x2F;working-with-unsafe.html" rel="nofollow">http:&#x2F;&#x2F;doc.rust-lang.org&#x2F;nightly&#x2F;nomicon&#x2F;working-with-unsafe...</a> for elaboration).<p>Furthermore, I reiterate my point from my earlier comment: if you&#x27;re going to have unsafe code anywhere, the standard libraries are exactly where you want it, and therefore the amount of unsafe code in libstd is unabashedly above average.<p>EDIT: I should also mention that not all `unsafe` blocks, even the interesting ones, pose the same difficulty to formal verification. In fact, my very-uneducated guess would be that liballoc, despite having relatively few uses of `unsafe`, will be the hardest to verify due to the fact that it contains the tricky `Rc` type.