# Terminology around unsafe, undefined behaviour, and invariants

**URL:** https://internals.rust-lang.org/t/terminology-around-unsafe-undefined-behaviour-and-invariants/12755
**Category:** Unsafe Code Guidelines
**Created:** [July 16, 2020, 10:42am UTC](https://internals.rust-lang.org/t/terminology-around-unsafe-undefined-behaviour-and-invariants/12755 "2020-07-16T10:42:32Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![zackw](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/zackw/32/2071_2.png) [@zackw](https://internals.rust-lang.org/u/zackw)
#### Post date: [July 18, 2020, 3:09pm UTC](https://internals.rust-lang.org/t/terminology-around-unsafe-undefined-behaviour-and-invariants/12755/11 "2020-07-18T15:09:13Z")

</div>

I also think "undefined behavior" is a problematic term and we should try to find something clearer.

When I've written documentation that touches on these issues for C, I find it works best to talk in terms of assumptions made by different parts of the implementation. Here's a couple of examples.

> `bool` occupies the same space as a `u8`, one byte, but the compiler generates code assuming that the numeric value of that byte is always either `0` or `1`.

> The following function [ed.: from [this old thread](https://internals.rust-lang.org/t/storing-a-smaller-length-of-a-slice-and-accessing-beyond-the-stored-length-but-inside-the-actual-length/12234/16)] reads memory beyond the space allocated to the slice `x`. This is incorrect, even if `x` is a subslice of a larger allocation, because the compiler will assume that it does no such thing while generating code for its callers.
> 
> ```rust
> fn reach_beyond(x: &[i32]) -> i32 {
> unsafe {
> *x.as_ptr().add(x.len()+1)
> }
> }
> 
> ```

A hypothetical Rust language standard would, in these terms, say that "the compiler may assume that (not X)" where the C standard says "the behavior is undefined if (X)".

---

_[View the full topic](https://internals.rust-lang.org/t/terminology-around-unsafe-undefined-behaviour-and-invariants/12755)._