On 6/7/26 01:58, Sebastian Wittmeier via Std-Proposals wrote:
> Is this truly UB (anything can go wrong, invalid program according to the standard, not just to the programmer's own rules) or a detected bug?

Disclaimer: I rely on https://cppreference.com/, not the actual text on
the standard. Quote from https://cppreference.com/:

If lock is called by a thread that already owns the mutex, the behavior
is undefined: for example, the program may deadlock. An implementation
that can detect the invalid usage is encouraged to throw a
std::system_error with error condition resource_deadlock_would_occur
instead of deadlocking.

This looks unambiguous to me. It is valid for the program to deadlock,
which is what must happen if the underlying implementation cannot (or
chooses not to) detect the deadlock. It is valid for the program to
throw. It is also valid for anything else to happen, because this is
undefined behavior, not unspecified behavior. It is valid to segfault.
It is valid to start mining bitcoins. It is valid for the program to
erase itself from disk. And it is valid for the program to leave itself
in an inconsistent state and then throw. Technically the entire
computer could be in an inconsistent state, not just the process.
Undefined behavior means all bets are off.

In practice, if you're writing non-portable code anyway and you know
that your specific C++ implementation throws on deadlock while leaving
the rest of the program in a consistent state, you can take advantage of
that knowledge. Just be aware that this may not work on any other C++
implementation. It's analogous to the way POSIX provides a whole bunch
of non-standard guarantees for C standard library functions that only
apply to POSIX environments.

-- 
Rainer Deyke - rainerd_at_[hidden]