Open
Conversation
This is getting better but is still not great. More work needs to be done.
ksbeattie
reviewed
Apr 4, 2026
Comment on lines
+16
to
+17
| Of the CWE Top 25 Most Dangerous Software Weaknesses in 2025,<sup>[1]</sup> six are directly related to memory access errors in unsafe languages like C++: out-of-bounds write (5), use after free (7), out-of-bounds read (8), buffer copy without checking size of input (11), null pointer dereference (13), and stack-based buffer overflow (14). | ||
| (However, note that this is a significant reduction from the 2023 list, where memory errors occupied the top three spots: use after free (1), heap-based buffer overflow (2), and out-of-bounds write (3).<sup>[2]</sup>) |
Contributor
There was a problem hiding this comment.
I think these might be more readable as a lists, with a clearer indication that the number is the ranking, not a count. Something like "#5" or "5th".
ksbeattie
reviewed
Apr 4, 2026
|
|
||
| Of the CWE Top 25 Most Dangerous Software Weaknesses in 2025,<sup>[1]</sup> six are directly related to memory access errors in unsafe languages like C++: out-of-bounds write (5), use after free (7), out-of-bounds read (8), buffer copy without checking size of input (11), null pointer dereference (13), and stack-based buffer overflow (14). | ||
| (However, note that this is a significant reduction from the 2023 list, where memory errors occupied the top three spots: use after free (1), heap-based buffer overflow (2), and out-of-bounds write (3).<sup>[2]</sup>) | ||
| So while memory safety issues did not dominate the reported memory vulnerabilities in 2025, memory-safety bugs remain one of the most persistent sources of serious software defects and security vulnerabilities. |
Contributor
There was a problem hiding this comment.
Is it "memory safety" or "memory-safety"? Just be consistent, either way.
ksbeattie
reviewed
Apr 4, 2026
| The C++ standards work suggests how the remaining major categories could be addressed more systematically. | ||
| A future profiles framework could combine a `std::bounds` profile to inject bounds checks, a `std::lifetime` profile to reject manual `delete` and `free` and to check for null dereference, and a `std::initialization` profile to verify that objects are initialized before use.<sup>[11],[12],[13]</sup> | ||
| That same direction could then be extended with a `std::type` profile to restrict unsafe casts and wrong-type access, plus an invalidation profile to prevent use of iterators, pointers, references, and views after a container mutation or destruction.<sup>[14],[17]</sup> | ||
| Together with custom `clang-tidy` checks that discourage persistent raw C++ references, uture LLVM lifetime and invalidation analysis, and other rule checks, this can create a subset of C++ that could come reasonably close to being memory safe in practice for most HPC C++ programs, while still maintaining near maximum performance.<sup>[5],[6],[11]</sup> |
Contributor
There was a problem hiding this comment.
Suggested change
| Together with custom `clang-tidy` checks that discourage persistent raw C++ references, uture LLVM lifetime and invalidation analysis, and other rule checks, this can create a subset of C++ that could come reasonably close to being memory safe in practice for most HPC C++ programs, while still maintaining near maximum performance.<sup>[5],[6],[11]</sup> | |
| Together with custom `clang-tidy` checks that discourage persistent raw C++ references, future LLVM lifetime and invalidation analysis, and other rule checks, this can create a subset of C++ that could come reasonably close to being memory safe in practice for most HPC C++ programs, while still maintaining near maximum performance.<sup>[5],[6],[11]</sup> |
ksbeattie
requested changes
Apr 4, 2026
Contributor
ksbeattie
left a comment
There was a problem hiding this comment.
A couple of minor, easy to fix changes suggested.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
EB Member: @bernhold
Resolves Blog planning
#252PR checklist for files displayed on bssw.io site
@mentionthe BSSw.io editorial board member@<eb-member-id>in Description above assigned to shepherd your PR.<issue-id>in the Description above for the associated GitHub Issue.wikize_refs.py -i <base>.mdis run and commit (if using wikize_refs.py).*.mdfile(s) as rendered in GitHub for this PR.<eb-member-id>.<pr-author-id>.content: <content-type>for the type of contribution.Content Development(see Content Development).*.mdfile(s) (setPublish: yes).preview(so PR branch will be merged to 'preview' branch and watch for possible merge failures).[ ] [Author] Ensurewikize_refs.py -i <base>.mdis run and commit (if using wikize_refs.py).@betterscientificsoftware/bssw-maint(BSSw Maint) asking to carry out final publication steps.NOTE:
@betterscientificsoftware/bssw-maintteam (hint: type@,b,s,s,w,-,mto auto-complete to@betterscientificsoftware/bssw-maint).