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.