Skip to content

Commit f3af182

Browse files
authored
Updated Safe C++ references - "indefinite hiatus" (#437)
1 parent d7265ba commit f3af182

File tree

3 files changed

+15
-23
lines changed

3 files changed

+15
-23
lines changed

contributor-guide/modules/ROOT/pages/contributors-faq.adoc

Lines changed: 11 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -299,41 +299,33 @@ Financial contributions or sponsorships as a token of appreciation are rare!
299299

300300
. *As a contributor of a library to Boost, what do I need to know about Safe pass:[C++]?*
301301
+
302-
Currently, https://safecpp.org/P3390R0.html[Safe pass:[C++]] is a proposal, under discussion, to develop a memory-safe set of extensions to pass:[C++]. The push is because the current lack of memory safety makes it too easy for malicious software to exploit language vulnerabilities and perform a variety of attacks. Safe pass:[C++] would provide robust memory-safe, type-safe, and thread-safe operations.
302+
The current lack of memory-safety makes it too easy for malicious software to exploit pass:[C++] language vulnerabilities and perform a variety of attacks. However, retrofitting the pass:[C++] language with memory-safe constructs has proven to be daunting. The https://safecpp.org/P3390R0.html[Safe pass:[C++]] proposal for a memory-safe set of operations is currently in a state of indefinite hiatus.
303303
+
304-
Clearly there could be significant interest in safe versions of Boost libraries, though the level of work involved extends well beyond rewriting a library using the safe extensions, as _all_ dependencies would also have to be safe versions too.
304+
Clearly there could be significant interest in safe versions of Boost libraries, though the level of work involved extends well beyond rewriting a library using safe extensions, as _all_ dependencies would also have to be safe versions too.
305305
+
306-
Both the stakes and the workloads are high! If the proposal leads to a solid set of extensions, then as a library developer you will have a decision to make - whether to refactor your library using these extensions, or not. Many factors might influence this decision.
306+
Currently, an astute developer should use known safe practices (some of which are shown below), avoid unsafe libraries if there is a choice, and be aware of the discussions on safe coding practices going on in social media.
307307

308-
. *Is Safe C++ part of Boost?*
308+
. *What kind of feedback did the proposal for Safe C++ receive?*
309309
+
310-
No, it is an independent initiative. The pass:[C++] Alliance has partnered with Sean Baxter, a key proponent of Safe pass:[C++], to further develop the proposal, and seek feedback from developers, researchers, and other stakeholders to refine the project's scope.
311-
312-
. *Is there an official release schedule for Safe C++?*
313-
+
314-
No, it is still at the proposal and design refinement stage.
315-
316-
. *What kind of feedback has the proposal garnered so far?*
317-
+
318-
Positive feedback centers on appreciation of the initiative to address longstanding safety concerns in pass:[C++]. More challenging feedback has included concerns about the complexity of integrating new safety features into the existing pass:[C++] framework, balancing enhanced safety with the language's core design features of performance and flexibility, and competition from the https://www.rust-lang.org/[RUST] and https://developer.apple.com/swift/[Swift] programming languages.
310+
Positive feedback centered on appreciation of the initiative to address longstanding safety concerns in pass:[C++]. More challenging feedback has included concerns about the complexity of integrating new safety features into the existing pass:[C++] framework, balancing enhanced safety with the language's core design features of performance and flexibility, and competition from the https://www.rust-lang.org/[RUST] and https://developer.apple.com/swift/[Swift] programming languages.
319311

320312
. *Are there references I can read that will help me understand safe concepts and so understand the online discussions?*
321313
+
322-
Yes, in addition to the https://safecpp.org/P3390R0.html[Safe pass:[C++] proposal] from Sean Baxter, the https://herbsutter.com/2024/03/11/safety-in-context/[pass:[C++] safety, in context] blog post, by Herb Sutter, has been written for a broad audience. Also by Herb Sutter, there is a paper entitled https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf[Core safety Profiles: Specification, adoptability, and impact].
314+
Yes, in addition to the, now stalled, https://safecpp.org/P3390R0.html[Safe pass:[C++]] proposal, the https://herbsutter.com/2024/03/11/safety-in-context/[pass:[C++] safety, in context] blog post, by Herb Sutter, has been written for a broad audience. Also by Herb Sutter, there is a paper entitled https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf[Core safety Profiles: Specification, adoptability, and impact].
323315
+
324-
If you refer to the *References* section of any of these papers, you will find a range of books, papers, presentations and the like that delve to various depths into safety issues. For example, the https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/p2816r0.pdf[Safety Profiles:Type-and-resource Safe programming in ISO Standard pass:[C++]], by Bjarne Stroustrup and Gabriel Dos Reis, outlines a talk on the broad spectrum of safety issues in a chattier style than the more formal programming papers - and might be a good place to start!
316+
If you refer to the *References* section of any of these papers, you will find a range of books, papers, presentations and the like that delve to various depths into safety issues. For example, the https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/p2816r0.pdf[Safety Profiles: Type-and-resource Safe programming in ISO Standard pass:[C++]], by Bjarne Stroustrup and Gabriel Dos Reis, outlines a talk on the broad spectrum of safety issues in a chattier style than the more formal programming papers - and might be a good place to start!
325317

326318
. *Can you recommend some Boost libraries that demonstrate current best safe-coding practices?*
327319
+
328320
By examining the source code and documentation for any of these libraries, you should be able to educate yourself on a robust approach to safe programming, using current development tools.
329321
+
330-
For _memory safety_, boost:smart_ptr[] provides smart pointer types like `boost::shared_ptr`, `boost::weak_ptr`, and `boost::scoped_ptr` to manage dynamic memory safely and avoid common pitfalls like memory leaks and dangling pointers. boost:pool[] offers memory pooling utilities that efficient managing of memory allocations while minimizing fragmentation. It can help show how to avoid unsafe manual memory management.
322+
For _memory-safety_, boost:smart_ptr[] provides smart pointer types like `boost::shared_ptr`, `boost::weak_ptr`, and `boost::scoped_ptr` to manage dynamic memory safely and avoid common pitfalls like memory leaks and dangling pointers. boost:pool[] offers memory pooling utilities that efficient managing of memory allocations while minimizing fragmentation. It can help show how to avoid unsafe manual memory management.
331323
+
332-
For _type-safety_, boost:static-assert[] facilitates compile-time checks with `BOOST_STATIC_ASSERT`, ensuring that certain conditions are met during compilation, thus improving type safety. Also, boost:type-traits[] supplies a set of tools for type introspection, enabling safer template programming by providing ways to query and manipulate types.
324+
For _type-safety_, boost:static-assert[] facilitates compile-time checks with `BOOST_STATIC_ASSERT`, ensuring that certain conditions are met during compilation, thus improving type-safety. Also, boost:type-traits[] supplies a set of tools for type introspection, enabling safer template programming by providing ways to query and manipulate types.
333325
+
334326
For _resource-safety_ boost:filesystem[] is designed to work with file paths and directories safely, minimizing errors in handling filesystem resources and ensuring proper cleanup. boost:scope_exit[] provides a mechanism for ensuring cleanup of resources (e.g., releasing locks or closing file handles) when a scope is exited, both normally or due to an exception. And boost:interprocess[] facilitates safe and efficient interprocess communication (IPC), managing shared memory and other resources in a resource-safe way.
335327
+
336-
For _thread-safety_ boost:thread[] offers portable thread management and synchronization primitives (such as `boost::mutex`, `boost::lock_guard`) to help developers write thread-safe code. boost:asio[] enables asynchronous I/O operations with an emphasis on thread safety, making it easier to build safe and scalable networked applications. At a lower level, boost:atomic[] provides atomic operations for thread-safe programming, avoiding data races in concurrent applications.
328+
For _thread-safety_ boost:thread[] offers portable thread management and synchronization primitives (such as `boost::mutex`, `boost::lock_guard`) to help developers write thread-safe code. boost:asio[] enables asynchronous I/O operations with an emphasis on thread-safety, making it easier to build safe and scalable networked applications. At a lower level, boost:atomic[] provides atomic operations for thread-safe programming, avoiding data races in concurrent applications.
337329
+
338330
For a more general approach to safety, boost:optional[] introduces a way to handle optional values safely, avoiding issues like null pointer dereferencing.
339331
boost:variant2[] provides a type-safe `union` type, ensuring that only one active type is stored at any time, preventing type misuse errors. boost:coroutine2[] implements stackful coroutines with resource management in mind, preventing unsafe usage patterns.
@@ -667,7 +659,7 @@ There are several libraries that provide functionalities for input validation, s
667659

668660
. *Are there Boost libraries that help with secure memory management?*
669661
+
670-
You can leverage various libraries to help ensure memory safety, prevent memory-related vulnerabilities, and manage resources efficiently:
662+
You can leverage various libraries to help ensure memory-safety, prevent memory-related vulnerabilities, and manage resources efficiently:
671663
+
672664
* boost:smart_ptr[] provides smart pointer classes such as `shared_ptr`, `unique_ptr`, and `weak_ptr`, which help manage dynamic memory allocation and deallocation automatically. By using smart pointers, you can prevent common memory-related vulnerabilities such as memory leaks, dangling pointers, and double frees.
673665
+

user-guide/modules/ROOT/pages/faq.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -954,7 +954,7 @@ Refer to the xref:contributor-guide:ROOT:index.adoc[]. Note that shareware libra
954954

955955
. *I use Boost Libraries in my current projects. What do I need to know about Safe pass:[C++]?*
956956
+
957-
Currently, https://safecpp.org/P3390R0.html[Safe pass:[C++]] is a proposal, under discussion, to develop a memory-safe set of extensions to pass:[C++]. There is no current timeline for release of these extensions, but for more information, refer to xref:contributor-guide:ROOT:contributors-faq#safecpp[Contributors FAQ: Safe pass:[C++]], and for terminology explanations see xref:glossary.adoc#s[Glossary: S].
957+
Retrofitting the pass:[C++] language with memory-safe constructs has proven to be daunting. The https://safecpp.org/P3390R0.html[Safe pass:[C++]] proposal for a memory-safe set of operations is currently in a state of indefinite hiatus. For more information, including current safe coding practices, refer to xref:contributor-guide:ROOT:contributors-faq#safecpp[Contributors FAQ: Safe pass:[C++]]. For terminology - refer to xref:glossary.adoc#s[Glossary: S].
958958

959959
== Smart Pointers
960960

user-guide/modules/ROOT/pages/glossary.adoc

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -359,16 +359,16 @@ _This diagram shows the basic process of quantum teleportation, where the unknow
359359
[[s]]
360360
== S
361361

362-
*Safe pass:[C++]* : Currently a https://safecpp.org/P3390R0.html[proposal for a memory-safe set of pass:[C++] operations]. Key concepts of memory safety include:
362+
*Safe pass:[C++]* : There are memory-safe discussions and initiatives going on in the wider pass:[C++] development world, though it seems like it's a tough nut to crack. The https://safecpp.org/P3390R0.html[Safe pass:[C++]] proposal is currently in a state of indefinite hiatus. Key concepts of _memory-safety_, and it's partners _type-safety_ and _thread-safety_, include:
363363

364364
* *Borrowing* : this refers to a feature of an ownership system that allows a variable to grant temporary access to its data without giving up ownership. _Immutable borrowing_ allows others to read but not modify data. Multiple immutable borrows are allowed at the same time. With _mutable borrowing_ others can modify the data, but only one mutable borrow is allowed at any one time (to prevent data races), and the owner cannot modify the value until the borrow ends. Borrowing enforces lifetimes - so borrowed references do not outlive the original data.
365365
* *Borrow checking* : a kind of compile-time analysis that prevents using a reference after an object has gone out of scope.
366366
* *Choice types* : a _choice type_ is similar to an enum, but contains a type-safe selection of alternative types.
367367
* *Explicit mutation* : all mutations are explicit, so there are no uncertain side-effects.
368368
* *Interior mutability* : types with interior mutability implement deconfliction strategies to support shared mutation, without the risk of data races or violating exclusivity.
369369
* *Pattern matching* : the only way to access alternatives of _Choice types_ to ensure type-safety.
370-
* *Relocation object model* : a memory model that supports relocation/destruction of local objects, in order to satisfy type safety.
371-
* *Send and sync* : these are _type traits_ that ensure memory safety between threads. The _send_ is enabled for a variable if it is safe to transfer ownership of its value to another thread. A _sync_ trait is enabled if it is safe to share a reference to a value with other threads.
370+
* *Relocation object model* : a memory model that supports relocation/destruction of local objects, in order to satisfy type-safety.
371+
* *Send and sync* : these are _type traits_ that ensure memory-safety between threads. The _send_ is enabled for a variable if it is safe to transfer ownership of its value to another thread. A _sync_ trait is enabled if it is safe to share a reference to a value with other threads.
372372
* *The `safe` context* : operations in the `safe` context are guaranteed not to cause undefined behavior.
373373

374374
*SHA* : Secure Hash Algorithm, a function that will reliably give different hash values for different inputs.

0 commit comments

Comments
 (0)