Skip to content

Commit

Permalink
Fixed uninitialized typo
Browse files Browse the repository at this point in the history
  • Loading branch information
seanbaxter committed Sep 13, 2024
1 parent af70299 commit e78bd2a
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 2 deletions.
2 changes: 1 addition & 1 deletion docs/draft.html
Original file line number Diff line number Diff line change
Expand Up @@ -556,7 +556,7 @@ <h2 data-number="1.2" id="extend-c-for-safety"><span class="header-section-numbe
behaviors. Sometimes these operations are prohibited by the compiler
frontend, as is the case with pointer arithmetic. Sometimes the
operations are prohibited by static analysis in the compiler’s
middle-end; that stops use of initialized variables and use-after-free
middle-end; that stops use of uninitialized variables and use-after-free
bugs, and it’s the enabling technology of the <em>ownership and
borrowing</em> safety model. The remainder of issues, like out-of-bounds
array subscripts, are addressed with runtime panic and aborts.</p>
Expand Down
2 changes: 1 addition & 1 deletion proposal/draft.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ The foreignness of Rust for career C++ developers combined with the the friction

The goal of this proposal is to advance a superset of C++ with a _rigorously safe subset_. Begin a new project, or take an existing one, and start writing safe code in C++. Code in the safe context exhibits the same strong safety guarantees as code written in Rust.

Rigorous safety is a carrot-and-stick approach. The stick comes first. The stick is what security researchers and regulators care about. Safe C++ developers are prohibited from writing operations that may result in lifetime safety, type safety or thread safety undefined behaviors. Sometimes these operations are prohibited by the compiler frontend, as is the case with pointer arithmetic. Sometimes the operations are prohibited by static analysis in the compiler's middle-end; that stops use of initialized variables and use-after-free bugs, and it's the enabling technology of the _ownership and borrowing_ safety model. The remainder of issues, like out-of-bounds array subscripts, are addressed with runtime panic and aborts.
Rigorous safety is a carrot-and-stick approach. The stick comes first. The stick is what security researchers and regulators care about. Safe C++ developers are prohibited from writing operations that may result in lifetime safety, type safety or thread safety undefined behaviors. Sometimes these operations are prohibited by the compiler frontend, as is the case with pointer arithmetic. Sometimes the operations are prohibited by static analysis in the compiler's middle-end; that stops use of uninitialized variables and use-after-free bugs, and it's the enabling technology of the _ownership and borrowing_ safety model. The remainder of issues, like out-of-bounds array subscripts, are addressed with runtime panic and aborts.

The carrot is a suite of new capabilities which improve on the unsafe ones denied to users. The affine type system makes it easier to relocate objects without breaking type safety. Pattern matching, which is safe and expressive, interfaces with the extension's new choice types. Borrow checking,[@borrow-checking] the most sophisticated part of the Safe C++, provides a new reference type that flags use-after-free and iterator invalidation defects at compile time.

Expand Down

0 comments on commit e78bd2a

Please sign in to comment.