From b6cf288741e6aee52fb0aedfc1cad7761f442303 Mon Sep 17 00:00:00 2001 From: Alexis Beingessner Date: Tue, 14 Jul 2015 00:26:08 -0700 Subject: [PATCH] fix via mdinger --- repr-rust.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/repr-rust.md b/repr-rust.md index caf60be..a1f5f29 100644 --- a/repr-rust.md +++ b/repr-rust.md @@ -109,7 +109,7 @@ struct FooRepr { And indeed this is approximately how it would be laid out in general (modulo the size and position of `tag`). However there are several cases where -such a representation is ineffiecient. The classic case of this is Rust's +such a representation is inefficient. The classic case of this is Rust's "null pointer optimization". Given a pointer that is known to not be null (e.g. `&u32`), an enum can *store* a discriminant bit *inside* the pointer by using null as a special value. The net result is that @@ -121,4 +121,4 @@ nested enums pooling their tags into a single descriminant, as they are by definition known to have a limited range of valid values. In principle enums can use fairly elaborate algorithms to cache bits throughout nested types with special constrained representations. As such it is *especially* desirable that -we leave enum layout unspecified today. \ No newline at end of file +we leave enum layout unspecified today.