A set of papers related to safety in July mailing list.

Since this is a topic that is interesting to many (including myself), I checked what the July mailing list has relevant to the safety topic and collected here what I found more relevant:

- A framework to systematically classify UB: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3100r7.pdf

- core_ub: a run-time profile to guarantee lack of UB: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4317r0.pdf

- an initialization profile. This profile tries to give a guaranteed set of guaranteed initialization rules, banning impossible to analyze ones, statically: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4222r1.pdf


- deny by default + positive rules: a framework for invalidation detection with fewer annotations. This one is more of research than some of the other papers INHO right now, but looks interesting. Its main insight is that by adding deny by default combined with UB classification + as a default deny rule and a second layer of positive rules, combined with strict aliasing, annotations can be reduced to detect a subset of safety: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4296r0.pdf

- subsetting: banning unsafe constructs and usages through annotations to make the language safer by default. Collections of such rules could yield some specific profile or subset of profiles: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3716r1.html

- on activating profiles proposes what the semantics of activating a profile should or should not be: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4314r0.html

- implicit contract assertions and profiles: this paper, among others, argues whether the base vehicle for implicit contract assertions should be a language feature or just a profile and explains that point of view in the matter: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4306r0.pdf

The papers related to pure contracts were intentionally left out since there are so many, but some are tangentially or directly related to the topic of safety.

Part of these papers lean on other foundational papers, such as yheprofiles framework (not from July mailing itself): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3589r2.pdf

I hope you enjoy it!


https://redd.it/1v0hynk
@r_cpp

A better bitset for enum flags
https://www.elbeno.com/blog/?p=1836

https://redd.it/1v0pizv
@r_cpp

Euro LLVM 2026: All talks related to C++ security

The recent Euro LLVM conference has several talks related to clang improvements that are either recent, in the process of eventually be pushed into upstream, or still in research status:

- Extending Lifetime Safety: Verification of [[clang::noescape] annotation](https://youtu.be/9Wcc7phM6kE?si=88ZZt6Gtj1zImMj)
- [Adding Nullability Checking and Annotations to Many Millions of Lines of Code](https://youtu.be/KzIRpQgRE0M?si=gZ1fnf7VHX5EeqNk)
- [Bounds Checking with the Clang Static Analyzer: Improvements and Insights](https://youtu.be/QisZYmCW9Rc?si=iUSuU5jSrnNaNQm)
- Finding Injection Vulnerabilities: Improvements of the Taint Analysis of the Clang static analyzer
- Capabilities Great and Small: CHERI, CHERIoT, and LLVM

All in all, a good overview of what clang can actually do today, with annotations as well, and what is being envisioned on the various security discussions.

https://redd.it/1v0ut9j
@r_cpp

I've invented labeled loop breaks

And now I don't believe it wasn't invented before, but I can't find any info on it. How long ago was it invented? Why isn't it used widely or even mentioned anywhere? What are the downsides?
Here's the main idea:

// Keyword - for, while, or do
// Tag - custom loop name
// ... - loop body
#define looptag(keyword, tag, ...)\
keyword(VAARGS)\
if(false)\
{\
tag##break: break;\
tag##continue: continue;\
}\
else\
/Here goes your loop body/

Here is the playground

https://redd.it/1v0s5da
@r_cpp