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
Copy file name to clipboardExpand all lines: contributor-guide/modules/ROOT/pages/contributors-faq.adoc
+11-19Lines changed: 11 additions & 19 deletions
Original file line number
Diff line number
Diff line change
@@ -299,41 +299,33 @@ Financial contributions or sponsorships as a token of appreciation are rare!
299
299
300
300
. *As a contributor of a library to Boost, what do I need to know about Safe pass:[C++]?*
301
301
+
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 memorysafety 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.
303
303
+
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.
305
305
+
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.
307
307
308
-
. *Is Safe C++ part of Boost?*
308
+
. *What kind of feedback did the proposal for Safe C++ receive?*
309
309
+
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.
319
311
320
312
. *Are there references I can read that will help me understand safe concepts and so understand the online discussions?*
321
313
+
322
-
Yes, in addition to thehttps://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].
323
315
+
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!
325
317
326
318
. *Can you recommend some Boost libraries that demonstrate current best safe-coding practices?*
327
319
+
328
320
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.
329
321
+
330
-
For _memorysafety_, 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.
331
323
+
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 typesafety. 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.
333
325
+
334
326
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.
335
327
+
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 threadsafety, 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.
337
329
+
338
330
For a more general approach to safety, boost:optional[] introduces a way to handle optional values safely, avoiding issues like null pointer dereferencing.
339
331
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
667
659
668
660
. *Are there Boost libraries that help with secure memory management?*
669
661
+
670
-
You can leverage various libraries to help ensure memorysafety, 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:
671
663
+
672
664
* 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.
Copy file name to clipboardExpand all lines: user-guide/modules/ROOT/pages/faq.adoc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -954,7 +954,7 @@ Refer to the xref:contributor-guide:ROOT:index.adoc[]. Note that shareware libra
954
954
955
955
. *I use Boost Libraries in my current projects. What do I need to know about Safe pass:[C++]?*
956
956
+
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].
Copy file name to clipboardExpand all lines: user-guide/modules/ROOT/pages/glossary.adoc
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -359,16 +359,16 @@ _This diagram shows the basic process of quantum teleportation, where the unknow
359
359
[[s]]
360
360
== S
361
361
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:
363
363
364
364
* *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.
365
365
* *Borrow checking* : a kind of compile-time analysis that prevents using a reference after an object has gone out of scope.
366
366
* *Choice types* : a _choice type_ is similar to an enum, but contains a type-safe selection of alternative types.
367
367
* *Explicit mutation* : all mutations are explicit, so there are no uncertain side-effects.
368
368
* *Interior mutability* : types with interior mutability implement deconfliction strategies to support shared mutation, without the risk of data races or violating exclusivity.
369
369
* *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 typesafety.
371
-
* *Send and sync* : these are _type traits_ that ensure memorysafety 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.
372
372
* *The `safe` context* : operations in the `safe` context are guaranteed not to cause undefined behavior.
373
373
374
374
*SHA* : Secure Hash Algorithm, a function that will reliably give different hash values for different inputs.
0 commit comments