I understand now, thank you.

> On 10/11/2026 21.17, Peter Dimov via SG7 wrote:
>
> > Lauri Ojell-Vasama wrote:
> >> Any non-trivial debug printing, despite only reading, is still unsafe
> >> due to unknowable concurrent access and state of initialization in the
> target object.
> >> In the best case you get nonsense debug output due to a torn read,
> >> and in the worst an exploitable vulnerability.
> > This doesn't make much sense to me. If I have
> >
> > template<class T> void f( T const& x ) {
> > std::format( "x={:?}", x );
> > // do other things involving x
> > }
> >
> > if `x` is being concurrently modified even though it has been passed
> > to `f`, then all those other things involving `x` are as undefined as
> > printing it, if we assume our traditional thread safety model.
> My apologies, perhaps my explanation was unclear. It's not that I'm assuming
> an invalid use of `x`, but rather it is possible that `x` itself has internal threads
> making concurrent accesses to its own private data members, or that it may
> have members in invalid states (e.g. a dangling string_view that due to internal
> invariants is never used in that state). Until now, the assumption that no
> external actor is able to access those members, and in doing so invoke
> undefined behaviour, has been a safe one. C++26 breaks that assumption.
> >> Given that this is a debugging feature intended mainly for logging
> >> and the like, it seems especially important for it not to introduce
> >> further safety issues. From what I can tell, the only safe solution
> >> to this problem is to define a debug dumping facility that never
> >> automatically follows pointers (e.g. in string views, as sad as that
> >> is for the quality of the debug output).
> > The default debug output doesn't automatically follow any pointers, yes.
> > That's because the default prints the subobjects in order, and
> > printing a pointer doesn't follow the pointer.
> >
> > This isn't a problem with string views, because they define their own
> > printing support (both nondebug and debug) and don't use the default.
>
> Yes, I'm not supposing that such a debug printer would follow simple pointers.
> My point was that following any pointer, even indirectly (e.g.
> in the printing of a string_view) is unsafe, because there is no way to know
> whether the pointer is valid, or whether reading a pointer-size pair results in a
> valid view.
>
> More generally, I would say that given an arbitrary `T const& x`, while printing
> `x` may be considered safe, applying any non-trivial formatting to its private
> data members with unknown invariants and state should be considered
> unsafe.
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7