On Saturday 7 September 2024 18:31:27 CEST Marc Mutz via Development wrote:
> Another thing I neglected to mention is that there are two distinct
> steps here. The first is to change certain Q_ASSERT()s into Q_PRE()
> (say) precondition checks that optionally throw on violation. This has
> nothing
Hi,
I don't see how
On 06.09.24 22:34, Thiago Macieira wrote:
[...]
> In turn this means there's no support for throw-on-violations for Qt code in
> production.
[...]
necessarily follows, at least as long as we speak about a Qt-proprietary
mechanism.
Another thing I neglected to mention is tha
On Saturday 7 September 2024 16:19:20 CEST Marc Mutz via Development wrote:
> So I fail to see how throwing precondition handlers, siting, security-wise,
> smack between the Q_ASSERT and unchecked UB modes we already support
> right _now_, could be any less acceptable than these polar ends? It's
>
Nothing that you describe in the context of a bug in our code here is
specific to throwing precondition checkers. If you weren't checking with
active precondition handlers (the status quo in release mode atm), then
you'd likely would have run into language UB on precondition violation,
with equ
