# Role of UB / uninitialized memory

**URL:** https://internals.rust-lang.org/t/role-of-ub-uninitialized-memory/5399
**Category:** Unsafe Code Guidelines
**Created:** [June 13, 2017, 11:58am UTC](https://internals.rust-lang.org/t/role-of-ub-uninitialized-memory/5399 "2017-06-13T11:58:47Z")
**Posts on this page:** 1
**Showing post:** 28

<div class="post-metadata">

### Author: ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)
#### Post date: [June 14, 2017, 8:45pm UTC](https://internals.rust-lang.org/t/role-of-ub-uninitialized-memory/5399/28 "2017-06-14T20:45:53Z")

</div>

> [@Canvas unsafe code in the wild](https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-wild/4990/49):
>
> > [@](#):
> >
> > So in C, padding bytes are special-cased in several places with the intention that you can always interact with a struct safely (byte-by-byte or otherwise) as long as all of its value fields have been initialized. Specifically, padding bytes have unspecified, but never indeterminate, values. That would be a sensible way to deal with them in Rust if it doesn't already work that way.
> 
> I can't see why anyone would want to disagree with this, so I stashed it away to "resolved issues" in my head.

Oh, I missed that comment. And I don't think it is true. I already quoted `malloc` above as yielding indeterminate values; the padding bytes of a struct will usually stay indeterminate. In fact, a quick search for "padding" in the standard brings up "The contents of ‘‘holes’’ used as padding for purposes of alignment within structure objects are indeterminate."

> [@Canvas unsafe code in the wild](https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-wild/4990/50):
>
> First off, let's settle the general assumption: Undefined behavior is bad. If it's not intuitive, it's even worse. Things should only be classified as undefined behavior if doing them necessarily breaks assumptions programmer makes about the code. More to the point, giving the compiler freedom to do more optimizations is not by itself a sufficient argument to make something UB. There are numerous examples where C code doesn't work as expected, because of things that are counterintuitively defined to be UB. Notorious examples in C are signed integer overflow and strict aliasing rules. They break correct-looking programs, silently. Any disagreements?

I think there is general agreement in the unsafe code guidelines team that there are some optimizations we want to do on safe code, and that we are willing to make things UB for that purpose. See [https://github.com/nikomatsakis/rust-memory-model/tree/master/optimizations](https://github.com/nikomatsakis/rust-memory-model/tree/master/optimizations) for some examples. I agree that UB is bad, but slow code is also bad. This is a trade-off. Making fewer things UB is one way to improve the situation here; another one that we are looking into is making UB _testable_. That would be a big thing, and put us in a totally different spot than where C sits. If we have a way to run your test suite in "UB checking mode", so that you can be _sure_ it doesn't do anything the compiler doesn't want you to do -- that makes it much less of a problem for the UB rules to be subtle. Still, we want them to be as "un-subtle" as reasonable while still permitting sufficient optimization. After all, if people use C or assembly over Rust for reasons of performance, we haven't gained much in terms of overall safety. (Also notice that the UB rules will only ever affect people the use `unsafe`, so most Rust programmers should not have to care.)

Also, is some forum moderator reading this? I think most everything since [https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-wild/4990/23](https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-wild/4990/23) is interesting discussion and very valuable feedback, but it's not on-topic in this thread any more, so maybe we could have it split into a new thread?

---

_[View the full topic](https://internals.rust-lang.org/t/role-of-ub-uninitialized-memory/5399)._