You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>References can be taxonimized into two classes:<spanclass="citation" data-cites="second-class">[<ahref="https://borretti.me/article/second-class-references" role="doc-biblioref">second-class</a>]</span></p>
896
908
<ul>
897
909
<li>First-class references can pass data into functions, be returned
adding simplified safe references was an easy extension. If the
990
1002
community is able to fill in our gaps in knowledge around this sort of
991
1003
reference, the compiler could accommodate those advances as well.</p>
992
-
<h1data-number="3" id="other-aspects-of-safety"><spanclass="header-section-number">3</span> Other aspects of safety<ahref="#other-aspects-of-safety" class="self-link"></a></h1>
1004
+
<h1data-number="4" id="other-aspects-of-safety"><spanclass="header-section-number">4</span> Other aspects of safety<ahref="#other-aspects-of-safety" class="self-link"></a></h1>
993
1005
<p>As detailed in the Safe C++<spanclass="citation" data-cites="safecpp">[<ahref="https://safecpp.org/draft.html" role="doc-biblioref">safecpp</a>]</span> proposal, there are four
recent Android study on memory safety<spanclass="citation" data-cites="android">[<ahref="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1" role="doc-biblioref">android</a>]</span>, the benefits of rewriting are
1024
1036
often not worth the costs. What we have to prioritize is the transition
1025
1037
to safe coding practices<spanclass="citation" data-cites="safe-coding">[<ahref="https://blog.google/technology/safety-security/tackling-cybersecurity-vulnerabilities-through-secure-by-design/" role="doc-biblioref">safe-coding</a>]</span> for new code.</p>
[android] Eliminating Memory Safety Vulnerabilites at the Source. <ahref="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1"><divclass="csl-block">https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1</div></a>
<p>References can be taxonimized into two classes:<spanclass="citation" data-cites="second-class">[<ahref="https://borretti.me/article/second-class-references" role="doc-biblioref">second-class</a>]</span></p>
896
908
<ul>
897
909
<li>First-class references can pass data into functions, be returned
adding simplified safe references was an easy extension. If the
990
1002
community is able to fill in our gaps in knowledge around this sort of
991
1003
reference, the compiler could accommodate those advances as well.</p>
992
-
<h1data-number="3" id="other-aspects-of-safety"><spanclass="header-section-number">3</span> Other aspects of safety<ahref="#other-aspects-of-safety" class="self-link"></a></h1>
1004
+
<h1data-number="4" id="other-aspects-of-safety"><spanclass="header-section-number">4</span> Other aspects of safety<ahref="#other-aspects-of-safety" class="self-link"></a></h1>
993
1005
<p>As detailed in the Safe C++<spanclass="citation" data-cites="safecpp">[<ahref="https://safecpp.org/draft.html" role="doc-biblioref">safecpp</a>]</span> proposal, there are four
recent Android study on memory safety<spanclass="citation" data-cites="android">[<ahref="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1" role="doc-biblioref">android</a>]</span>, the benefits of rewriting are
1024
1036
often not worth the costs. What we have to prioritize is the transition
1025
1037
to safe coding practices<spanclass="citation" data-cites="safe-coding">[<ahref="https://blog.google/technology/safety-security/tackling-cybersecurity-vulnerabilities-through-secure-by-design/" role="doc-biblioref">safe-coding</a>]</span> for new code.</p>
[android] Eliminating Memory Safety Vulnerabilites at the Source. <ahref="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1"><divclass="csl-block">https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1</div></a>
Copy file name to clipboardExpand all lines: lifetimes/P3444R0.md
+8Lines changed: 8 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,14 @@ author:
9
9
toc: false
10
10
---
11
11
12
+
# Abstract
13
+
14
+
This proposal describes the implementation of a memory-safe reference type that does not use lifetime annotations. The goal of the proposal is to:
15
+
16
+
1. Explore the viability of memory safety without lifetime parameters.
17
+
2. Explain the infeasibility of making legacy lvalue and rvalue references memory safe.
18
+
3. Address common objections to safety models that use lifetime annotations.
19
+
12
20
# Safe references
13
21
14
22
"Safe C++"[@safecpp] introduced a comprehensive design for compile-time memory safety in C++. The borrow checking model in Safe C++ requires lifetime parameters, a feature that increases expressiveness but complicates the language's type system. This proposal describes an alternative style of borrow checking, guaranteeing lifetime safety without the involvement of lifetime annotations.
Copy file name to clipboardExpand all lines: lifetimes/draft-lifetimes.md
+8Lines changed: 8 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,14 @@ author:
9
9
toc: false
10
10
---
11
11
12
+
# Abstract
13
+
14
+
This proposal describes the implementation of a memory-safe reference type that does not use lifetime annotations. The goal of the proposal is to:
15
+
16
+
1. Explore the viability of memory safety without lifetime parameters.
17
+
2. Explain the infeasibility of making legacy lvalue and rvalue references memory safe.
18
+
3. Address common objections to safety models that use lifetime annotations.
19
+
12
20
# Safe references
13
21
14
22
"Safe C++"[@safecpp] introduced a comprehensive design for compile-time memory safety in C++. The borrow checking model in Safe C++ requires lifetime parameters, a feature that increases expressiveness but complicates the language's type system. This proposal describes an alternative style of borrow checking, guaranteeing lifetime safety without the involvement of lifetime annotations.
0 commit comments