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.

> 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.